Performance Analysis of Mobile Agents for Filtering Data...

Copyright 2000 by the authors.�To appear in journal Mobile Networks and Applications (ACM MONET), 2001.�Available at ftp://ftp.cs.dartmouth.edu/TR/TR2000-377.ps.Z�

Performance Analysis of Mobile Agentsfor Filtering Data Streams on Wireless Networks

David Kotz, George Cybenko, Robert S. Gray, Guofei Jiang, and Ronald A. PetersonDartmouth CollegeHanover NH 03755

[email protected]

Martin O. Hofmann, Daria A. Chacon, and Kenneth R. WhitebreadLockheed Martin Advanced Technology Laboratories

Camden NJ 08102�mhofmann,darnold,kwhitebread�@atl.lmco.com

James HendlerDARPA ISO

Arlington VA [email protected]

Dartmouth Technical Report TR2000-377

Abstract

Wireless networks are an ideal environment for mobileagents, since their mobility allows them to move across anunreliable link to reside on a wired host, next to or closerto the resources that they need to use. Furthermore, client-specific data transformations can be moved across the wire-less link and run on a wired gateway server, reducing band-width demands. In this paper we examine the tradeoffsfaced when deciding whether to use mobile agents in a data-filtering application where numerous wireless clients filterinformation from a large data stream arriving across thewired network. We develop an analytical model and use pa-rameters from filtering experiments conducted during a U.S.Navy Fleet Battle Experiment (FBE) to explore the model’simplications.

1. Introduction

Mobile agents are programs that can migrate from hostto host in a network of computers, at times and to places oftheir own choosing. Unlike applets, both the code and the

This research was supported by the DARPA CoABS Program(DARPA contracts F30602-98-2-0107 and F30602-98-C-0162 for Dart-mouth and Lockheed Martin respectively) and by the DoD MURI program(AFoSR contract F49620-97-1-03821 for both Dartmouth and LockheedMartin).

execution state (heap and stack) move with the agent; un-like processes in process-migration systems, mobile agentsmove when and where they choose. They are typically writ-ten in a language that can be interpreted, such as Java, Tcl,or Scheme, and thus tend to be independent of the operatingsystem and hardware architecture. Agent programmers typ-ically structure their application so that the agents migrateto the host(s) where they can find the desired service, data,or resource, so that all interactions occur on the local host,rather than across the network. In some applications, a sin-gle mobile agent migrates sequentially from host to host; inothers, an agent spawns one or more child agents to migrateindependently.

A mobile-agent programmer thus has an option not avail-able to the programmer of a traditional distributed applica-tion: to move the code to the data, rather than moving thedata to the code. In many situations, moving the code maybe faster, if the agent’s state is smaller than the data thatwould be moved. Or, it may be more reliable, since the ap-plication is only vulnerable to network disconnection dur-ing the agent transfer, not during the interaction with theresource. For a survey of the potential of mobile agents,see [CHK97, GCKR00].

These characteristics make mobile-agent technology es-pecially appealing in wireless networks, which tend to havelow bandwidth and low reliability. A user of a mobilecomputing device can launch a mobile agent, which jumpsacross the wireless connection into the wired Internet. Once

there, it can safely roam among the sites that host mobileagents, interacting either with local resources or, when nec-essary, with resources on remote sites that are not willing tohost mobile agents. Once it has completed its task, it canreturn to (or send a message to) its user, using the wirelessnetwork.

Clearly the agent case avoids the transmission of un-necessary data, but does require the transmission of agentcode from client to server. The total bandwidth consumedfor code transmission depends on the agent size and arrivalrate. For most reasonable agent code sizes and arrival rates,the savings in data transmission may be much larger thanthe code transmissions. Of course, each client’s code couldbe pre-installed on the server.1 This approach presupposes,however, that the clients are known in advance. In manyof the environments that we consider, new clients with newcode can appear at any time, and possibly disappear only ashort while later. In scenarios like the one discussed in thispaper, we need at least a dynamic-installation facility, andmobile agents give us the flexibility to move filtering codeto any point in the network, and to move the code again asthe situation changes. Although we do not consider suchmulti-machine scenarios in this initial paper, they will be animportant part of future work.

In this paper we analyze the potential performance bene-fits of mobile agents in a typical data-filtering scenario. Thescenario is based on a filtering experiment that was con-ducted during a U.S. Navy Fleet Battle Experiment (FBE).In the FBE experiment, mobile agents were sent across awireless link from the U.S.S. Coronado to a shore-basedintelligence database, where they filtered incoming intel-ligence reports to find and return only those reports rele-vant to the Coronado’s current mission. Although the sce-nario is drawn from an actual military exercise, it is suffi-ciently general to reflect many applications, from militaryapplications in which soldiers monitor weather, terrain andtroop movements, to commercial applications in which con-sumers monitor stock reports and news stories.

In our scenario there are numerous information produc-ers, each of which pushes out a steady stream of infor-mation, such as weather observations, stock quotes, newsstories, traffic reports, plane schedules, troop movements,and the like. Clearly each source has a different data rateand frequency. There are also numerous information con-sumers, whose computers are connected to a wireless net-work channel. We assume that the information streamsgather at a gateway server, which then transmits the dataacross the wireless channel to the consumers. Although wemodel a single server machine, in a large system we expectthat the server would be a multiprocessor or cluster, such

1In fact, most mobile-agent systems include, or plan to include, somekind of code-caching functionality, so that the agent code is transferredonly the first time that an agent visits a machine.

as those used in large Internet servers today. Although wemodel a single wireless channel, the results are easily exten-sible to multiple channels, each with its own server, whetherin separate or overlapping regions.

Each consumer is interested in a different (but not nec-essarily disjoint) subset of the data. In particular, each con-sumer is interested in only a few information streams, andthen only in some filtered set of items in those streams. Forexample, a traveler might monitor the weather stream, butnot the stock stream, and of the weather stream, might careonly about the weather in those locations that she will visittoday. The first step requires no computation; the secondmay require some computation related to the size of the datastream. We model a consumer’s interests as a set of tasks,all running on that consumer’s single computer client.

We compare two approaches to solving this problem:

1. The server combines and broadcasts all the datastreams over the wireless channel. Each client receivesall of the data, and each task on each client machine fil-ters through the appropriate streams to obtain the de-sired data.

2. Each task on each client machine sends one mobileagent to the server. These “proxy” agents filter the datastreams on the server, sending only the relevant data asa message to the corresponding task on the client.

We use two performance metrics to compare these twotechniques: the bandwidth required and the computationrequired. We can directly compare the usage of the twotechniques, and we can evaluate the capacity needed in theserver or the network. Clearly, the mobile agent approachtrades server computation (and cost) for savings in net-work bandwidth and client computation, a valuable tradeoffif bandwidth is limited or if it is important to keep clientweight and power requirements (and cost) low.

In the next section, we present the FBE experiment inmore detail. Then, in two subsequent sections, we definethe parameters that arise during the analysis, derive the ba-sic equations, and interpret their significance. In Section 4,we review the parameter values that we were able to obtainfrom the actual FBE experiment, and describe the experi-ments that we performed to obtain values for other key pa-rameters. In Section 5, we use these values to explore theperformance space given by our model. We describe somerelated work in Section 6 and summarize in Section 7.

2. The Fleet Battle Experiment

In practice, the United States Navy (USN) Fleet BattleExperiment (FBE) series involves information-flow archi-tectures that exemplify the general scenario described in the

2

introduction. In FBE-Echo, the fifth in the series, Lock-heed Martin Advanced Technology Laboratories (LM ATL)fielded CAST, a mobile-agent application that optimizedthe flow of critical information through bandwidth-limited,congested, and unreliable wireless networks [Cha99]. Asthe results later in this paper indicate, the mobile-agent so-lution lowers bandwidth consumption in the limited experi-ment scenario and promises to be even more beneficial in arealistic, high-intensity operation.

The USN Maritime Battle Center in Newport, Rhode Is-land, conducts semi-annual FBEs in cooperation with thenumbered USN fleets with the goal of streamlining and in-vigorating the Navy’s warfare concept development, doc-trine refinement and warfare innovation process. FBE-Echowas held in March 1999 in the San Francisco Bay area, andexamined operational and tactical requirements for warfarein the years 2005–2010. More than 15 ships and 12,000Sailors and Marines from southern California participated.The FBE-Echo hypothesis was that “warfighting processessupported by new concepts and technology allow the Navyto enter and remain in the [coastal region] indefinitely withthe ability to provide protection, weapons fires and C4I2

support to forces ashore.”3

At FBE-Echo, CAST was integrated into the Full Di-mension Protection Cell aboard the command ship, theU.S.S. Coronado. CAST spawned a set of mobile “scout”agents to correlate events indicative of impending The-ater Ballistic Missile (TBM) launches and send filtered re-ports back to the U.S.S. Coronado. CAST then suppliedalerts on TBM activity to the Air Operations Commander,who tasked fleet surveillance assets and launched a simu-lated preemptive strike. The scout agents traveled acrossthe SIPRNET, the secure military Internet, from the U.S.S.Coronado to a simulated shore-based intelligence feed. TheSIPRNET link between the U.S.S. Coronado and the shorewas a wireless Super High Frequency (SHF) satellite com-munications link, whose bandwidth was 768 kbps.4 Intelli-gence reports were approximately 150 bytes in size and ar-rived in bursts spaced about every four minutes, with eachburst containing five to ten reports at a rate of one reportevery four seconds. The CAST scout agents were about1 KByte in size.

The main benefit of CAST was that agents selectivelyscanned and filtered the incoming intelligence reports, for-warding only those that correlated to a significant event.The mobile scout agents carried selection specifications

2C4I is a military abbreviation for Command, Control, Communica-tions, Computers and Intelligence.

3Web Site: Fleet Battle Experiment Echo, Asymmetric UrbanThreat, http://www.nwdc.navy.mil/navigation/mbc.htm,last modified 8/31/00, last accessed 9/17/00.

4In this paper, we use K and M to mean powers of two (10 and 20,respectively) and k and m to mean powers of 10 (3 and 6 respectively).Thus kbps means �� bits per second.

from the U.S.S. Coronado across the wireless link to theremote information sources, stayed there to monitor newinformation, and periodically sent back a much reduced setof data, saving both bandwidth and operator attention to ir-relevant data. Each TBM event differs by the location, theinitiating event, the sets of reports, and the timelines, so thatan implementation without mobile filtering logic embodiedin a mobile scout agent would have been cumbersome andcomplex.

Another benefit of CAST’s mobile-agent approach wasits ability to handle network outages. The satellite connec-tion disconnected frequently, for a few seconds to an hourat a time. With a mobile-agent approach, the task of moni-toring the database was uninterrupted once agents were res-ident on shore, although, of course, reports that passed theagents’ filters had to be buffered until the link came backup. New agents were programmed to repeatedly attemptthe ship-to-shore leap as long as the satellite connection wasdown.

In the exercise, the ratio of relevant to irrelevant reportswas only about 0.5, since the simulated intelligence feed didnot create a realistic number of extraneous “noise” events,and a scout agent was spawned approximately every 4 min-utes. In an actual high-intensity operation, the number ofextraneous reports will be much higher and drive the ratioof relevant to irrelevant reports down to at least 0.005. Espe-cially in an urban scenario, a large number of reports wouldbe generated by MTI (Moving Target Indicator) and ELINT(Electronic Intelligence) sources. The JSTARS MTI sensor,for example, is capable of reporting on 100 targets everysecond. A real conflict would involve several JSTARS andother sensor platforms. In such a situation, CAST wouldlaunch a larger number of scouts, up to a rate of 10 per sec-ond. The remaining parameters are identical for exerciseand actual scenarios.

LM ATL has tailored the CAST mobile agents to severalother military applications, including the DARPA SmallUnit Operations program and U.S. Army intelligence op-erations [HMW98]. In each case, mobile agents proved tobe effective in mitigating the effects of bandwidth-limited,unreliable, wireless networks.

To fully explore the general scenario presented by theFBE-Echo CAST experiments, we developed an analyticmodel. The model considers a more general scenario in-volving multiple clients (whereas CAST had one, the U.S.S.Coronado) and multiple independent streams of reports. Inthe rest of this paper we present our model and sample someof the performance space using specific parameters.

3. The model

Since the data is arriving constantly, we think of the sys-tem as a pipeline; see Figure 1. We imagine that, during a

3

time interval �, one chunk of data is accumulating in the in-coming network buffers, another chunk is being processedon the server, another chunk is being transmitted across thewireless network, and another chunk is being processed bythe clients. If the data arrives at an average rate of � bits persecond, the average chunk size is �� bits.

Server

ClientClient

ClientInformationdata streams

Wirelessnetwork

Internet

TI TS TW TC

Figure 1. The scenario viewed as a pipeline.

For the pipeline to be stable, then, each stage must beable to complete its processing of data chunks in less than� time, on average (Figure 2). That is, �� , �� ,�� , and �� . In the analysis that follows wework with these steady-state assumptions; as future work,we would like to explore the use of a queueing model to bet-ter understand the dynamic properties of this system, suchas the buffer requirements (queue lengths).

0 t 2t 3t 4t 5t 6t 7t 8t

Server receives chunk from Internet, TI

Server processes chunk, TS

Server sends chunk across wireless, TW

Client processes chunk, TC

A

A

A

A

B

B

B

B

C

C

C

C

D

D

D

D

E

E

E

E

...

...

...

...

...

...

Time

Figure 2. The pipeline timing diagram. Theletters represent data chunks. For example,between time �� and �� chunk A is being pro-cessed by the clients, chunk B is being trans-mitted from the server to the clients, chunk Cis being processed by the server, and chunkD is being received by the server.

3.1. The parameters

Below we define all of the parameters used in our model,for easy reference.� � input data streams’ speed (bits/sec);� � time interval (seconds);� � ��, the size of a data chunk arriving during time

period � (bits);� � wireless channel’s total physical bandwidth

(bits/sec);�� communication overhead factor for broadcast

(�� );

�� , the effective bandwidth available for broad-cast (bits/sec);

�� communication overhead factor for agents(�� );

�� , the effective bandwidth available for agentmessages (bits/sec);

�� the bandwidth available in the server’s wired Inter-net connection, for receiving data streams (bits/sec);presumably �� ;

� number of client machines; � index of a client machine (� � � );�� number of tasks on each client machine ,� � � ;

� � index of a task (� � � � ��);� ��

��, total number of tasks; � arrival rate of new agents uploaded from the clients

to the server (per second);� � average agent size (bits);� �

�� the fraction of the total data� that task � on client chooses to process (by choosing to process only certaindata streams);

�� the fraction of the data processed by task � onclient , produced as output;

��

�� computational complexity of task � onclient (operations);5

� � the average computational complexity, for a given� ��

��

�

�� . It is a convenientshorthand.

�� average number of operations needed for a newagent to start and to exit;

�� performance of client machine (operations/sec);�� performance efficiency of the software platform on

the client machine (�� );� � performance of the server machine (opera-

tions/sec);6

� � performance efficiency of the software platform onthe server (� � �);

Notes. � is the raw bandwidth of the wireless channel, butthat bandwidth is never fully available to application com-munication. We assume that a broadcast protocol wouldactually achieve bandwidth �� and a mobile-agent messag-ing protocol would achieve bandwidth ��. In Section 4 wediscuss our measurements of �� and ��.

When comparing a mobile-agent approach to a more tra-ditional approach, it is most fair to expect that a traditionalsystem would use compiled code on the client (such ascompiled C code), whereas a mobile-agent system woulduse interpreted code on the server (because most mobile-agent systems only support interpreted languages like Java

5We expect that �� will have little dependence on�, directly, but moreon ��

��.

6We assume that all agents get equal-priority access to server cycles.

4

or Tcl). The client and server will likely be different hard-ware and have different speeds, �� and � , respectively. Be-cause the language, compiler, and run-time system imposeoverhead, the client runs at a fraction �� of the full speed��, and the server runs at a fraction � of the full speed � .Of course � � �, and we expect � � ��, since filteringagents on the server will be interpreted, whereas filteringcode on the clients will be compiled. On the other hand, weexpect � �� .

Computed values. As hinted in the figures above, the fol-lowing values are computed as a result of the other parame-ters.

�� The time for transmission across the Internet to theserver.

�� The time for processing on the server.�� The time for transmission across the wireless net-

work.�� The time for processing on the client.Most of these have two variants, i.e., ��, �� and ��

for the agent case, and ��, �� and �� for the broadcastcase.

3.2. Computing the constraints

As mentioned above, each stage of the pipeline mustcomplete in less than time �, that is, �� , �� ,�� , and �� .

Internet, �� . Since we are concerned with alternatives forthe portion of the system spanning the wireless network, wedo not specifically model the Internet portion. We assumethat the Internet is not the bottleneck, that is, it is sufficientlyfast to deliver all data streams on schedule:

��

��

� � (1)

� � �� (2)

of course.

Server, �� . In the broadcast case, the server simplymerges the data streams arriving from the Internet. Thisstep is trivial, and in any case �� almost certainly.

In the agent case, data filtering happens on the server.The server’s time is a combination of the filtering costs plusthe time spent initializing newly arrived agents:

��

�

��

��

��

��

��

� � � ��

(3)

If we know that the expected value of the computingcomplexity �� is �, then we can simplify and obtain a

bound on the number of client tasks (agents), �. That is,we assume that

��

�

��

� � �

��

� � (4)

Now �� ,

��

� � (5)

� � ��

�(6)

Wireless network, �� . The broadcast case is relativelysimple, since all of the chunk data � is sent over the chan-nel:

��

��

� � (7)

� � �� (8)

Recall that �� , and that � � ��.In the agent case, agents filter out most of the data and

send a subset of the data items across the wireless network,as messages back to their task on the client. Agent�� sends,on average, ��

�� bits from a chunk. The total time totransfer all agents’ messages is thus

��

��

�

��

��

� � (9)

If we consider the average agent and define

� ��

�

�

��

� �

�� (10)

then, since there are � agents,

��

��

� � (11)

It is not quite that simple, however.The wireless channel also carries agents from the clients

to the server, so we must adjust for the bandwidth occupiedby traffic in the reverse direction.7 Recall that new agentsof size � jump to the server at a rate per second. Thisactivity adds � bits per second ( �� bits per chunk) tothe total traffic. So, updating equation (11) we have

��

��

� � (12)

which leads to a bound on the number of agents (tasks):

� ��

�� (13)

7Unless the channel is full duplex, in which case there is no impact onthe downlink bandwidth. Here we assume a half-duplex channel.

5

When does the mobile-agent approach require less wire-less bandwidth? We can compute the bandwidth neededfrom the amount of data transmitted for one chunk, ex-panded by �� to account for the protocol overhead, thendivide by the time � for one chunk:

�

��

��

�

��

�� (14)

�� (15)

� ��

� ��

��

� �

�� (16)

Note that inequality (16) is nearly the same as inequal-ity (13). If broadcast is possible (� � ��), then we shoulduse broadcast iff � exceeds the limit provided in inequal-ity (16). If broadcast is impossible (� � ��), then of coursethe mobile-agent approach is the only choice, but the num-ber of agents must be kept within the limit specified in (13).

Note that in the broadcast case the wireless bandwidthmust scale with the input stream rate, while in the agentcase the wireless bandwidth must scale with the number ofagents and the relevance of the data. Since we expect thatmost of the data will be filtered out by agents (i.e., � �� ), the agent approach should scale well to systems withlarge data-flow rates and moderate client populations.

Client, �� . We consider only the processing needed tofilter the data stream, and assume that the clients have ad-ditional power and time needed for an application-specificconsumption of the data. Also, we assume the client hassufficient processing power to launch agents at rate �.

In the broadcast case, the data filtering happens on theclients. We must design for the slowest client, i.e.,

��

��

��

��

��

��

(17)

If all client hosts were the same, we could write simply

��

�

��(18)

and since �� is required,

� � ��

�(19)

In the agent case there is no data filtering on the clients,so �� .

3.3. Commentary

The results are summarized in Table 1.

We can see that the agent approach fits within the con-straints of the wireless network if the number (� and ) andsize (�) of agents is small, or the filtering ratios (� �� ) arelow.

We believe that, in many realistic applications, mostagents will remain on the server for a long time, and newagents will be installed rarely. Thus, is small. Most of thetime, � �. This assumption simplifies some of the equa-tions into a more readable form, as shown in the right sideof the table.

Notice that the broadcast case scales infinitely with thenumber of clients, but to add tasks to a client or to add datato the input stream requires the client processor to be faster.On every client

��

��

��

��

��

� � (20)

��

��

��

��

��

�� (21)

so, as � or � increases or as �� (the range of �) increases,�� must increase.

The mobile-agent case, on the other hand, requires littlefrom the client processor (for filtering), but requires a lotmore from the server processor. That processor must scalewith the input data rate, the number of clients, and the num-ber of tasks per client.

� ��

�� (22)

On the other hand, it may be easier to scale a server in afixed facility than to increase the speed of individual clientmachines, especially if the server lives in a comfortable ma-chine room while the clients are mobile, battery-operatedfield machines.

Buffers in the pipeline. Since we model our applicationas a pipeline, we are primarily concerned with throughputand bandwidth, rather than response time and latency. Aslong as the pipeline is stable in the steady state, i.e., no com-ponent’s capacity is exceeded, the system works. All of ourabove calculations are based on that approach.

In a real system, of course, the data flow fluctuates overtime. Buffers between each stage of the pipeline hold datawhen one stage produces data faster than the next stage canprocess it. In a more complete analysis we would use a fullqueuing model to analyze the distribution of buffer sizes ateach stage of the pipeline, given distributions for parameterslike �, , and ��. We leave this analysis for future work.

Latency. Although we are most concerned with through-put, in our application some clients may also be concerned

6

Table 1. Summary of the constraints derived earlier, along with simplified constraints that assume� � �. �� and �� are not affected by �. At the bottom, we show the comparison where agents requireless wireless bandwidth than the broadcast approach.

Limits Simplified LimitsStage Broadcast Agent Broadcast AgentInternet, ��

Server, �� negligible � � ��

0 � � ��

Wireless, ��

� � ��

��

Client, ��

negligible � � ��

negligibleComparison Simplified Comparison

Wireless, ��

� ��

��

� ��

� ��

��

about latency. In other words, it would be a shame iftime-critical data were delayed from reaching the client.Which approach leads to less latency, say, from the timeit reaches the server until the time it reaches the client ap-plication? Consider the flow of a specific data item throughthe pipeline: it is processed on the server, transmitted on thewireless network, and processed on the client. It must shareeach of these resources with other data items in its chunk,and it must share the server and wireless network with otherclients. On average, each of � agents may require only�

�� CPU time on the shared server. If the server divides

its time finely and evenly, all tasks will complete their com-putation at time ��. If the server divides its time coarsely,the average task completes in half that time, at time �

��.

A similar analysis can be made for the wireless network.Assuming fine-grain sharing of the server and network,

the latencies are

�� (23)

�� (24)

If we ignore the arrival of new agents (i.e., � �), andassume that all clients are identical, we have

��

� � ��

��

� � (25)

��

��

��

��(26)

Unfortunately it is difficult to compare these two withoutspecific parameter values.

We wonder, however, about the value of such a latencyanalysis. Given a specific data rate �, one must choose aserver speed, wireless network bandwidth, and client speed,that can just keep up with the data flow. That is, in time in-terval � those three components must each be able to process� data. Their latency is ��. With sufficiently small �, say,1–10 seconds, it seems likely this latency would suffice formost applications. Although one approach may have a littleless latency than the other, the data flow rate remains the

same. One could reduce latency by making balanced im-provements to the two components with non-zero latency;this improvement may be easier in the agent approach, be-cause it may be easier to upgrade the server than thousandsof clients.

4. Model parameters

To explore some of the performance space representedby the model, we need reasonable values for key param-eters. In the context of the Fleet Battle Experiment (Sec-tion 2) we have � � � � kbps and � � �� bits. Usingthe extrapolation to a realistic situation, FBE-Echo antici-pates � �� , � ��/second, and � � �� kbps(based on 5 sensors, each generating 100 reports per second,at 150 bytes per report). This combination of parameters isrealistic and conservative, in that it allows the broadcast ap-proach to succeed (because � � �).8 Let us presume that anaverage agent monitors 2 of the 5 sensors, that is, � � � ��.Thus, if we accumulate reports for a � � �� second interval,the total amount of data � � mbits, and the agent mustprocess �� mbits.

Unfortunately CAST was not instrumented to record anyspecific information about the computational cost or soft-ware overhead � of the CAST agents. Thus, to measure thevalue of the other model parameters, we constructed a smalltest environment consisting of two Linux laptops, a Linuxworkstation cluster, and a wireless network. One laptopserved as the wireless client machine. The other laptop ranrouted to serve as a gateway between the 2 Mbps wire-less network and the 10 mbps wired network. Our servercluster contained 14 Linux workstations. We treated the 14machines as a single logical server, because we needed thatmany to effectively measure ��, as we describe below. Theplatform can be envisioned as shown in Figure 3.

When measuring parameters related to mobile

8In practice, the SHF satellite network was congested due to other traf-fic; although we do not model this congestion, it would only lead to astronger case for mobile agents since they require less bandwidth.

7

Cli

ent

Wir

eles

s ch

anne

l

Serv

er c

lust

er

Swit

ch

Wir

edE

ther

net

Wir

ed/w

irel

ess

gate

way

Figure3.Theexperimentalplatform,inwhich

theserverisaclusterofworkstations,send-

ingitsdatathroughawirelessgateway

ma-

chinetothewirelessnetwork.

[Clie

nt:

Gat

eway

Solo

2300

lapt

op;

Inte

lPe

ntiu

mM

MX

200

MH

z,48

MB

RA

M,r

unni

ngL

inux

2.0.

36.

Gat

eway

:Te

cra

500C

Sla

ptop

;In

tel

Pent

ium

120

MH

z,16

MB

RA

M,

runn

ing

Lin

ux2.

2.6.

Serv

ers:

VA

Lin

uxV

arSt

atio

n28

,Mod

el28

71E

;Pen

tium

IIat

450

MH

z,51

2KE

CC

L2

Cac

he,2

56M

BR

AM

,run

-ni

ngL

inux

2.0.

36.

Wir

edne

twor

k:th

ega

tew

ayw

asco

nnec

ted

toa

10m

bps

Eth

erne

t,th

roug

ha

hub,

a10

mbp

ssw

itch,

and

a10

0m

bps

switc

h,to

the

serv

ercl

uste

r.W

irel

ess

netw

ork:

2M

bps

Luc

entW

aveL

AN

“Bro

nze

Tur

bo”

802.

11b

PCca

rds

confi

gure

dat

2M

bps.

]

agen

ts,

we

used

the

Dar

tmou

thm

obile

-age

ntsy

stem

D’A

gent

s[G

ra97

,G

ra96

]as

anex

ampl

eof

aca

noni

cal

mob

ile-a

gent

plat

form

.A

lthou

ghth

eC

AST

appl

icat

ion

used

adi

ffer

ent

mob

ile-a

gent

plat

form

,it

was

suffi

cien

tlysi

mila

rto

D’A

gent

sfo

rth

epu

rpos

esof

the

expe

rim

ents

here

.

4.1.Measuring

�

Bec

ause

the

lang

uage

,co

mpi

ler,

and

run-

tim

esy

stem

impo

seov

erhe

ad,t

hecl

ient

runs

ata

frac

tion��

ofth

efu

llsp

eed��,

and

the

serv

erru

nsat

afr

acti

on�

ofth

efu

llsp

eed� .

Unf

ortu

nate

ly,

we

dono

tkn

owan

dca

nnot

di-

rect

lym

easu

re�

.9O

na

sing

leho

stof

spee

d�

,tho

ugh,

we

can

run

aco

mpi

led

Cpr

ogra

man

da

com

para

ble

Java

pro-

gram

,to

obta

in��

and� �

,and

divi

deto

obta

in��

We

wro

tea

sim

ple

imag

e-pr

oces

sing

appl

icat

ion

(an

edge

dete

ctor

)in

C,

and

then

port

edit

toJa

va.

We

ran

them

both

onon

eof

our

serv

ers,

usin

ga

sam

ple

imag

e;10

aver

aged

over

100

runs

,th

eJa

vapr

ogra

mto

ok11

1m

il-li

seco

nds

and

the

Cpr

ogra

mto

ok83

mil

lise

cond

s.In

this

mea

sure

men

t,w

ein

clud

eon

lyth

eco

mpu

tatio

nalp

ortio

nof

the

appl

icat

ion,

rath

erth

anth

etim

eto

read

and

wri

teth

e9R

ecal

lth

edi

fficu

ltyof

mea

suri

ngth

e“p

eak

perf

orm

ance

”of

anar

-ch

itect

ure,

and

all

the

disc

ussi

ons

abou

tth

eva

lue

ofM

Hz

and

MIP

Sas

met

rics

ofpe

rfor

man

ce.

10T

heim

age

size

was

308,

378

byte

s,or

2,46

7,02

4bi

ts,

appr

oxim

atel

yth

eva

lue��

��

��

mbi

tsw

em

entio

ned

abov

e.

imag

efil

es,

sinc

ein

our

mod

eled

appl

icat

ion

the

data

will

best

ream

ing

thro

ugh

mem

ory,

rath

erth

anon

disk

.T

hese

num

bers

give

� ��

��

,i.e

.,C

was

25%

fast

erth

anJa

va.

4.2.Measuring

�

The

raw

band

wid

thof

our

Wav

eLA

Nw

irel

ess

netw

ork

was

2M

bps

(tha

tis

,2,

097,

152

bps)

.To

obta

in�

val-

ues,

we

mea

sure

dth

etr

ansm

issi

onsp

eed

ofsa

mpl

eap

plic

a-tio

nstr

ansm

ittin

gda

taac

ross

that

netw

ork,

and

divi

ded

by2

Mbp

s.To

com

pute��

fort

hebr

oadc

astc

ase,

we

wro

tea

sim

ple

pair

ofpr

ogra

ms;

one

broa

dcas

t499

9da

tabl

ocks

of50

,000

byte

sea

chac

ross

the

wir

eles

sli

nk,f

orth

eot

her

tore

ceiv

e.T

hetr

ansm

issi

onco

mpl

eted

in11

35se

cond

s,w

hich

impl

ies

that

��

��

��

sec

(27)

��

��

��

��

bps

��

bps��

(28)

Inot

her

wor

ds,b

road

cast

ofth

ese

reas

onab

lyla

rge

chun

ksof

data

is84

%effic

ient

.To

com

pute��

for

the

agen

tca

se,

we

wro

tea

sim

ple

agen

tpro

gram

that

visi

tsth

ese

rver

,and

send

sab

out5

0K

Bof

docu

men

tsev

ery

3se

cond

s.T

heag

ent

com

plet

esaf

ter

send

ing

500

ofth

ese

50K

Bm

essa

ges.

The

effe

ctiv

eba

nd-

wid

this

com

pute

das

the

tota

lam

ount

ofda

tatr

ansm

itte

ddi

vide

dby

the

time

requ

ired

totr

ansm

itth

eda

ta,i

nclu

ding

the

time

slee

ping

.To

bette

rrefle

ctth

em

odel

edap

plic

atio

n,w

eac

tual

lyse

ntou

tsev

eral

agen

tsto

diff

eren

thos

tsw

ithin

our

serv

ercl

uste

r,an

din

crea

sed

the

num

ber

ofag

ents

and

host

sun

tilw

ere

ache

dth

ehi

ghes

tpos

sibl

eto

talb

andw

idth

.W

efo

und

that

14ag

ents

,ru

nnin

gon

sepa

rate

host

sw

ithin

the

serv

ercl

uste

r,re

ache

dal

mos

t1.5

mbp

s.Sp

ecifi

cally

,

��

��

��

��

bps

��

bps��

(29)

4.3.Measuring

��

Whe

nho

stin

gag

ents

,th

ese

rver

need

sto

supp

ort

all

ofth

eir

com

puta

tiona

lne

eds.

Inad

ditio

nto

the

proc

essi

ngtim

ere

quir

edtofil

ter

the

data

,ne

wag

ents

com

ean

dol

dag

ents

exit.

Inou

rmod

el,

agen

tsco

me

and

go,p

erse

cond

,on

aver

age.

We

mod

elth

eco

mpu

tati

onal

over

head

ofea

chag

ent’s

star

tand

exit

as��

.W

ew

rote

atr

ivia

lage

ntan

dar

rang

edfo

rone

ofou

rser

verh

osts

tora

pidl

ysu

bmit

agen

tsto

anot

her

serv

erho

st.

Aft

er50

00su

bmit

/exi

tpai

rsin

204

seco

nds,

we

conc

lude

that

the

over

head

��

isab

out

40m

illi

seco

nds

(act

uall

y,it

isth

enu

mbe

rof

oper

atio

nsco

rre-

spon

ding

to40

mil

lise

cond

s).

Itm

aybe

less

,be

caus

eou

rm

easu

rem

entw

asba

sed

onw

all-

cloc

kti

me,

notC

PUti

me,

and

this

expe

rim

entd

idno

tmax

outt

heC

PU.

8

5. Results

We now use these parameters in our equations to get asense of how they react under specific conditions.

Unfortunately it is difficult to get actual �, �, and � pa-rameters, although we did measure some ratios above. If weassume, however, that our edge-detection algorithm is rep-resentative of one sort of filtering operation, we do know thetime it took to execute that operation. On our client laptopwe measured

�

�� milliseconds (30)

That represents the time needed to process one 308 KByte(precisely, 2,467,024 bit) image; that is, approximately�� mbits for � � �� seconds. Equation 19 tellsus that

��

�(31)

� �� (32)

� �� (33)

That is, about 42 tasks per client, for an arbitrary numberof clients . Seen another way, if the filter requires 2.36%(236 milliseconds of the 10-second interval) of the client’sCPU, the client could support 42 such filters. Of course, theclient machine should reserve some power for consumingthe data after filtering, so it should not run anywhere closeto 42 filters.

Similarly, on the server, if we ignore , Equation 6 tellsus that

� � ��

�(34)

The machines we used as “servers” in our experiments werenot particularly speedy. It is more interesting to derive anequation for � in terms of the relative power of the serverand client, using quantities that we already have measured:

� ��

�� (35)

��

�

�

��

�� (36)

��

�� sec��

�

�� sec� (37)

� ��

��(38)

Figure 4 shows the total number of agents (for all clients)that could be supported as the power of the server � growsrelative to the power of the clients ��, for our 236 millisec-ond sample task as well as three other possibilities. Theplot shows ratios � �� reaching up to 20, which is easilyobtainable when clients are portable computers.

0

200

400

600

800

1000

1200

1400

1600

2 4 6 8 10 12 14 16 18 20

Max

imum

num

ber

of a

gent

s, m

Relative server power, Ss/Sc

1% of client

2.36% of client

10% of client

50% of client

Figure 4. The number of agents that can ef-fectively be supported, as the server powergrows relative to the client’s power. We showfour curves, representing different possiblecomputations; 2.36% represents our image-processing sample application. In the broad-cast case, each client could support 100 tasks(1%), 42 tasks (2.36%), 10 tasks (10%), or2 tasks (50%), for an arbitrary number ofclients.

In Figure 5 we show the constraints on �, in the agentcase. This graph plots the two constraints from Table 1,as � varies. The actual constraint is the minimum of thetwo curves. For lower � �� , the server’s computation isthe tighter constraint; for higher � �� , the wireless networkbandwidth limits us more. As a basis for drawing thesecurves, we reconsider the example inspired by FBE-Echo—that is, � � �� kbps, � � �� seconds, and � � � ��— andmeasure the image-processing application running on theserver (�� milliseconds, as described earlier).Of course, in nearly any application � will vary with � (andthus with � and �); for the purposes of this illustrative graphwe assume the computation is linear. In other words, weimagine that � may behave as follows.

�

� � � ��milliseconds�

�

�� sec� �� kbps(39)

In Figure 6 we look at similar results when we vary (the previous graph assumed � �). In Section 4.3 wemeasured

��

� ��milliseconds (40)

and in Section 4.1 we measured

�

� � � ��milliseconds (41)

and for a fixed � � �� seconds, the computational constraint

9

0

200

400

600

800

1000

1200

100 200 300 400 500 600 700 800 900 1000

Max

imum

num

ber

of a

gent

s, m

Input data rate, d (kbps)

Computational limitBandwidth limit, F’F = 0.005Bandwidth limit, F’F = 0.010Bandwidth limit, F’F = 0.020

Figure 5. The maximum number of agents�we can support, given the constraints in Ta-ble 1. Here� � �� kbps, � � �, �� ,� � �� seconds, and � is proportional to ,as described in the text. The computationallimit is coincidentally the same as the band-width limit for � � ��.

from Equation 6 is

� � ��

��

�� (42)

� ��

��ms�

��ms

��ms�� sec� (43)

Again, the actual constraint is the minimum of the twocurves. For lower � �� , the server’s computation is thetighter constraint; for higher � �� , the wireless networkbandwidth limits us more.

In Figure 6 the bandwidth-constraint lines are close tohorizontal, since in FBE-Echo the 1 KByte agents are smallenough that the transmission of the agents does not have asignificant effect on the wireless network. As shown in Fig-ure 7, on the other hand, the behavior is dramatically dif-ferent when the agents are larger. For large agents and highbirth/death rates, the traffic induced by the jumping agents( �) consumes the available bandwidth ��, leaving noth-ing for agents to transmit their data. Clearly, such a systemcan support few agents when the agent size is large or whenthe birth/death rate is high. This result emphasizes the needto include some kind of code caching in any mobile-codesystem, so that the same agent code is not transmitted re-peatedly across the wireless link.

Another useful way to look at the results is to graphthe bandwidth required by either the agent approach or thebroadcast approach, given certain parameters. In Figure 8we vary the filtering ratio, since it clearly has a large im-pact on the bandwidth required by the agent approach. Forlow filtering ratios, the agent approach needs less bandwidth

0

50

100

150

200

250

0 2 4 6 8 10

Max

imum

num

ber

of a

gent

s, m

Agent birth/death rate, r per second

Computational limitBandwidth limit, F’F = 0.005Bandwidth limit, F’F = 0.010Bandwidth limit, F’F = 0.020

Figure 6. The maximum number of agents� we can support, given the constraints inTable 1, as we vary �. Here we use pa-rameters � � � KByte, � � �� kbps,� � �� kbps, �� , � � �� sec-onds, ��

�� milliseconds, and�� milliseconds.

0

50

100

150

200

250

0 2 4 6 8 10

Max

imum

num

ber

of a

gent

s, m

Agent birth/death rate, r per second

Computational limitBandwidth limit, 1 KByte agents

Bandwidth limit, 10 KByte agentsBandwidth limit, 50 KByte agents

Figure 7. For comparison with Figure 6, wefix � � �� as in FBE-Echo, and insteaddisplay the bandwidth limit with � � �, 10,or 50 KBytes. Other parameters are the sameas in the preceding figure.

10

0

200

400

600

800

1000

1200

0.010 0.020 0.030 0.040 0.050

Req

uire

d ba

ndw

idth

(kb

ps)

Filtering Ratio F’F

Raw channel bandwidth BBroadcast approach bandwidth

Input bandwidth d

m=10

m=20

m=50

m=100m=200

Figure 8. The bandwidth requirements foragent and broadcast approaches. Here � �� kbps, � � �� kbps, � � ��/second,� � � KByte, �� , and �� . Note that the bandwidth required bythe broadcast approach is ��, and appearsabove �.

than the broadcast approach. If � � � (not shown), ofcourse the broadcast approach cannot work at all, and theagent approach is the only solution.

In Figure 9 we show the relationship between the numberof agents and the necessary filtering ratio. Another viewon the earlier charts, this clearly shows that, to support alarge number of agents, those agents must be aggressivelyfiltering the input stream.

In all, it is clear that there is a wide range of situationsin which mobile agents are more efficient than the broad-cast approach. Unless the number of clients is very large,the filtering ratio of each task is high, or the size or com-putational demands of each task is high, the mobile-agentapproach has promise.

6. Related work

Performance modeling of computer networks and dis-tributed applications is an old field, and our approach andresulting equations are similar to many previous analysesof distributed systems [Kin90]. In addition, there has beensome similar modeling work specifically for mobile-agentsystems.

Strasser and Schwehm [SS97] develop a general modelfor comparing the performance of Remote Procedure Calls(RPC) with the performance of migrating agents. Usingtheir model, which is best-suited for information-retrievalapplications, they derive equations for the total number ofbytes transferred across the network, as well as the totalcompletion time of the task. The equations include such

0.000

0.005

0.010

0.015

0.020

0.025

0.030

0.035

0.040

50 100 150 200 250 300 350 400

Nec

essa

ry f

ilter

ing

ratio

Number of agents

1-KByte agents3-KByte agents5-KByte agents

Figure 9. The relationship between the filter-ing ratio and the number of agents in theserver. Other parameters are as before: � �� kbps, � � �� kbps, � � � KByte,� � ��/second.

parameters as the expected result size and the “selectivity”of the agent (i.e., how much irrelevant information the agentfilters out at the data site, rather than carrying with it for fu-ture examination). Their byte equations are similar to ourbandwidth equations, although their time equations are notdirectly applicable to our scenario, since we are interestedonly in whether the server can keep up with the incomingdata streams, not with the total completion time.

Kupper and Park [KP98] examine a signaling applica-tion inside a telecommunications network, and compare amobile-agent approach with a stationary-agent (or client-server) approach. Starting with a queuing model of a hi-erarchical signaling network, they produce equations thatspecify the expected load on each network node in both themobile and stationary cases. These equations are similar toour server-load equations (from which we derive the con-straint on how many agents the server machine can handlesimultaneously).

Picco, Fuggetta and Vigna [Pic98, FPV98] identify threemain design paradigms that exploit code mobility: remoteevaluation, code on demand, and mobile agents. Withinthe context of a network-management application, i.e., thepolling of management information from a pool of networkdevices, they analyze these three paradigms and the tradi-tional client-server paradigm. They develop analytical mod-els to compare the amount of traffic around the network-management server, as well as the total traffic on the man-aged network. These models are similar to our bandwidthmodels.

More recently, Puliafito et al. [PRS99] use Petri netsto compare the mobile-agent, remote-evaluation and client-server paradigms. The key parameters to the models are

11

transition probabilities that specify (1) whether a traditionalclient or agent will need to redo an operation, and (2)whether a client or agent will need to perform another op-eration to continue with the overall task. Using the mod-els, they compare the mean time to task completion forthe three paradigms. Like the the work of Strasser andSchwehm [SS97], these Petri-net models are well suitedfor information-retrieval applications, are more general thanthe models in the other papers, and are not directly applica-ble to our scenario, which involves continuous filtering ofan incoming data stream, rather than a multi-step retrievaltask. Petri nets, however, could be a useful analysis tech-nique for our scenario.

In addition to the mathematical analyses above, therehas been a range of simulation and experimental work formobile-agent systems. Recent simulation work includes[SHG99], which considers the use of mobile agents forsearch operations on remote file systems (such as the stan-dard substring search of the Unix grep command), and[BP99], which examines the use of mobile agents for mes-sage delivery in ad-hoc wireless networks. Recent exper-imental work includes [SDSL99], which compares differ-ent strategies for accessing a Web database, and [GCKR00],which compares RPC and mobile-agent approaches for ac-cessing a document database. Although we have not donesimulation or experimental validation of our model yet,such validation is an essential part of future work.

In our broadcast scenario all of the data are broadcast.In our agent scenario each agent sends its own copy of thefiltered data to its client, regardless of whether other clientsmay also want the data. We may be able to use techniquesfrom the domain of “broadcast publishing” to obtain a moreefficient compromise approach [IV96].

7. Summary and future work

The FBE-Echo experiment is a good example of an ap-plication in which only a small portion of the available in-formation is relevant to the task at hand. Although the FBE-Echo experimental results suggested that mobile agentswere achieving significant bandwidth savings, the aggres-sive FBE testing schedule did not allow a direct comparisonwith a traditional client/server implementation. For this rea-son, we developed the model described in this paper, whichconfirms that mobile agents will often have a significant per-formance benefit in filtering applications. With small filter-ing ratios (� �� ) or a small numbers of agents, a mobile-agent approach can get by with less bandwidth or slower(i.e., cheaper or lighter) clients. At the same time, our anal-ysis reinforces the importance of the engineering challengeof keeping � and �� large, that is, reducing the overheadof mobile-agent computation and communication.

To further develop this performance analysis and to use

it in a wider range of applications, we need to better under-stand several issues: How variable is the input data streamin terms of its flow rate? In other words, how much buffer-ing would be necessary in the server and the clients? Howmany different agent/task types are there in typical applica-tions, and how widely do these types vary? How much CPUtime is needed to support the network protocols? Are aver-age or expected numbers acceptable, or do we need worst-case analysis?

Furthermore, we need to address a few limitations: (1)the broadcast case assumes that nobody misses any trans-missions, or that they do not care if they miss it, so thereare no retransmissions; (2) both cases ignore the client pro-cessing consumed by the end application; and (3) we con-sider only one application scenario. While the applicationscenario is widely representative, there are certainly otherapplication types worth analyzing. In particular, we wouldlike to consider scenarios in which the mobile agents moveup and down a hierarchy of gateway machines. We arealso interested in the use of mobile agents as a dynamicallydistributed, and redistributed, cooperative cache to supportmobile computers in a wireless network.

8. Acknowledgements

Many thanks for the helpful input from Daniela Rus,Jeff Bradshaw, Niranjan Suri, and the anonymous reviewersfor the Workshop on Modeling, Analysis and Simulation ofWireless and Mobile Systems (MSWiM 2000).

References

[BP99] S. Bandyopadhyay and K. Paul. Evaluating theperformance of mobile agent-based messagecommunication among mobile hosts in large adhoc wireless network. In Proc. of the 2nd ACMInt’l Workshop on Modeling, Analysis and Sim-ulation of Wireless and Mobile Systems, pages69–73. ACM Press, August 1999.

[Cha99] Daria A. Chacon. Small agents solv-ing large problems. Lockheed MartinATL Internal Report, 1999. Available athttp://www.atl.external.lmco.com/overview/library.html.

[CHK97] D. Chess, C. Harrison, and A. Kershenbaum.Mobile agents: Are they a good idea? InMobile Object Systems: Towards the Pro-grammable Internet, number 1222 in Lec-ture Notes in Computer Science, pages 25–47.Springer-Verlag, 1997.

12

[FPV98] A. Fuggetta, G. P. Picco, and G. Vigna. Under-standing code mobility. IEEE Transactions onSoftware Engineering, 24(5):342–361, 1998.

[GCKR00] R. S. Gray, G. Cybenko, D. Kotz, and D. Rus.Mobile agents: Motivations and state of the art.In Handbook of Agent Technology. AAAI/MITPress, 2000. To appear.

[Gra96] Robert S. Gray. Agent Tcl: A flexible and se-cure mobile-agent system. In Proceedings ofthe 1996 Tcl/Tk Workshop, pages 9–23, July1996.

[Gra97] Robert Gray. Agent Tcl: A flexible and se-cure mobile-agent system. PhD thesis, Dept.of Computer Science, Dartmouth College, June1997. Available as Dartmouth Computer Sci-ence Technical Report TR98-327.

[HMW98] Martin O. Hofmann, Amy McGovern, andKenneth R. Whitebread. Mobile agents onthe digital battlefield. In Proceedings of theSecond Internal Conference on AutonomousAgents (AA’98), pages 219–225. ACM Press,May 1998.

[IV96] T. Imielinski and S. Viswanathan. Wirelesspublishing: Issues and solutions. In Mo-bile Computing, chapter 11, pages 299–329.Kluwer Academic Publishers, 1996.

[Kin90] P. J. B. King. Computer and CommunicationSystem Performance Modeling. Prentice Hall,1990.

[KP98] A. Kupper and A. S. Park. Stationary vs. mo-bile user agents in future mobile telecommuni-cations networks. In Proc. of the Second Int’lWorkshop on Mobile Agents (MA ’98), volume1477 of Lecture Notes in Computer Science.Springer-Verlag, September 1998.

[Pic98] G. P. Picco. Understanding, Evaluating, For-malizing and Exploiting Code Mobility. PhDthesis, Dipartimento di Automatica e Informat-ica, Politecnico di Torino, 1998.

[PRS99] A. Puliafito, S. Riccobene, and M. Scarpa. Ananalytical comparison of the client-server, re-mote evalutaion and mobile agents paradigms.In Proc. of the 1st Int’l Symp. on Agent Systemsand Applications and 3rd Int’l Symp. onMobileAgents (ASA/MA99). IEEE Computer SocietyPress, October 1999.

[SDSL99] G. Samaras, M. Dikaiakos, C. Spyrou, andA. Liverdos. Mobile agent platforms for web-databases: A qualitative and quantitative as-sessment. In Proc. of the 1st Int’l Symp. onAgent Systems and Applications and Third Int’lSymp. on Mobile Agents (ASA/MA’99), pages50–64. IEEE Computer Society Press, October1999.

[SHG99] T. Spalink, J. H. Hartman, and G. Gibson. Theeffects of a mobile agent on file service. InProc. of the 1st Int’l Symp. on Agent Systemsand Applications and 3rd Int’l Symp. on Mo-bile Agents (ASA/MA’99), pages 42–49. IEEEComputer Society Press, October 1999.

[SS97] M. Strasser and M. Schwehm. A perfor-mance model for mobile agent systems. InProc. of the Int’l Conference on Parallel andDistributed Processing Techniques and Appli-cations (PDPTA’97), volume 2, pages 1132–1140, June 1997.

13

Performance Analysis of Mobile Agents for Filtering Data...

Documents

Transcript of Performance Analysis of Mobile Agents for Filtering Data...