Models for Analyzing Mobile Code
Gian Petro Picco, moderated by Gul Agha
Models for Scalable and Fault Tolerant Mobile Code
ft and scale are defining problems in distributed systems
not only problems to be solved when system is developed, but mob code
have been proposed as a solution - raison d'etre
not a technical impediment, but we should focus on what is the meaning of
the level of technology - mas, mob code
focus on mobile code rather than mobile agents
most research focuses on mas - most systems provide single abstraction - against
only one unit of mobility - move a process.
from theoretical and practical viewpoint, mas specialize mobile code.
what do we need at the mobile code level - not the other way around
we shouldn't get too hung up on ma's
no killer application found yet. complement rather than substitute things
what does it mean to be scalable?
mobile code proposed as a solution.
scalable is different than "must run over the internet."
is that the only application that we are trying to target?
there are other domains - example telecomunications, network management,
What is our notion of scalability
scale up as well as downwards
the ability to run code on pda's embedded device, etc....
shoot for the most general set of metrics, but generic is not good.
the application depends strongly on the domain.
why do you want 1000 agents on your machine, so what?
common view point- we are solving the problems of maybe ten companies...
how do I characterize a notion of scalability?
generic informal arguments, or precise quantitative ideas
concentrating interaction locally as opposed to spread
bypassing lossy links
need to convince people outside the field.
we haven't exploited fault tolerance - we haven't had our techniques adopted
in plain mobile code, I don't see the challenges.
just transfering messages. plenty of theories for doing that already.
different with agents- multiple hosts....
oversights- how to communicate with mobile agents. problems come from mobility
what is faulty? what are we trying to solve?
try to structure application to solve our problems once we have defiened them
how to evaluate tradeoffs
scalability and fault tolerance oppose one another
scale - compact, lightweight encoding
- reduce overhead, bandwidth, terse protocols
fault tolerance - redundancy makes stronger
what tradeoffs are good?
network management application, quantitivative
measure the amount on communicaiton between devices
find overhead of techniques and add in as well, but later
how much overhead is net management introducing?
build a modle of the net management task
how do we know how good technique is? need some quant. technique
mobile code is unconventional, need some convincing
networkk management is often pushed as good applicaiton of network management
in example, traffic overhead grows quadrically with mobile agents
note I have defined scalabiltiy metric precisely - netowkr communication
then look at characteristics of data that distinguish the remaining techniuqes
(mobile code and client server)
what about if mobile agent does some filtering - redefine what technique does
filtering - semantic compression - improves mobile agent
also in all other techniques, communication is pairwise
make assumptions clear - I want to minimize network traffic overhead
how much detail do you need?
We are trying to evaluate design with respect to parameters
if you look down at the protocol levels you can get further information
- example snmp on top of udp is much cheeper than java aglets
- on top of atp on top of tcp
- blows up network overhead
technology has big impact
again, this affects the analysis
now see what happens if you can change the underlying technology - send
a tcl script instead of an aglet
this is simple analysis, no cpu overhead
focus on one dimension, but provides deep insight
- limits of mobile code
- impact of mechanisms
- engineering criteria - we need guidlines in designing the system
- gives better arguments (numbers) for people outside the field
lessons to apply
scale and ft are analyzable
determine decision for mechanism to use
sometimes there are many actions that swim against the stream of good design
solve techprobems as well as problems within the field
keep scale and ft in mind with design
need general ideas as well as specific
need more quantitavtive evaluations
- Fred Schneider - what is the extent of computing systems driven by
performance analysis aas opposed to qualitative things like structuring
example, oop! generality isn't always fast
more than performance issues?
- Gian Pietro Picco - my analysis isn't just on performance. are we going the right direction. is there criteria that mobility is usefule? having quant is useful, but I aggree that there are ideas that are hard to capture. possible that if everything is ma, then design is extremely clear. butpeople need to ask qhat is our goal. we get caught up in what is most general, with risk of being generic. very difficult to use mobile code for everything, it is just a tool. why should we use it? we need to know why to use it. we have some background and experience with oop. our best experience with mobilce code is with applets. we need something that we can refer to and have people recognize immediatly
- David Kotz - agree, quantitave aren't the only thing. how convienent is it to measure? (see's that previous two agree) there aren't always metrice
- Fred Schneider - jini is example. provides scalability that you can't measure. how to measure ability to add devices on the network. non performance based scalabilty. how many secrets can you hide? scalability should be viewed sep f/perf.
- Gian Pietro Picco - jini situation uses rmi. simple invocation can cause complex actions w/o awareness. no insight of what happens. we need to focus on domain of applications. easy with scalability
- Larry Korba - are we arguing about the meaning of scalability?
- Gul Agha - performance is one, but not only metric. In lisp lots of issues that were considered bugs because of performance, are now considered features. one metric of scalabiltiy is use.
- Gian Pietro Picco - I never mentioned performance. network overhead is not performance. reflects scalability. not directly performance, but a way to get insights at your design.
- Gul Agha - welll, we want to see how performance degrades
- Gian Pietro Picco - science, we want a a way to validate our design
- David Kotz - performance also needs defining. you were speaking of performance in one context, there are many.
- Gul Agha - interested in claim of fundamental abstraction of mobile code rather than mobile agents. agent -> actor- with identity name state code etc, but also the possibility of autonomous migrations. own vs borrowing the resources. the usual notions of propery changes because of mobility so the notion of computation changes. negotiation of resources rather than ownership of resources.
- Peter Doemel - example of application where scalability is important. personal link - service by att in 1995. devices supported by mobile agents for communication. every user could submit agents to server. few big hp machines running like-telescript engine. filter email, fax important email, discard. agent meets you at hotel, etc. news service....
- Gul Agha - why is mobile
- Peter Doemel - personal agent you define and launch from pda. newservice- sign on to channels. another agent. everyone subscribed. all users' agents woke up at same time for a single event. 3k agents in one unix process, stalled machine swapping because every thread wanted same event at same time. redesign application. 1st approach ma's used for everything - didn't scale. second iteration didn't use ma and worked trivially
- Gian Pietro Picco - jini/rmi based on mobile code. but behaviour of your thread (nonmobile) can change. but your analysis has to change because there is mobile code underlying.
- Gul Agha - maybe not the abstraction you want...
- Gian Pietro Picco - if you have a modle that doesn't map well to your intents, then you need to do gymnastics
- Gul Agha - abstractions make your life easier. often with a lot of overhead. you can often get efficient implementations by easing abstraction at the low levels, covertly. example - compiler w/in scheme. implementation is not the abstration - there are different goals. use compiler technology to transform abstractions to efficient implementation
- Gian Pietro Picco - abstaractions are embedded into technology. if you're left w/ma abstraction you are shooting yourself in the foot. if you just have perspective on one abstraction, then you are missing a lot of flexibility, but let's go back to scale and ft.
- John McKim - I haven't heard anything about ft
- Pierre-Antoinne Queloz - what is the limit on the number of agents in the buffer. there is no mention of this in the slides. there are some environments whose features already limit the scalability of the entire system.
- Gul Agha - let's go back to actor liturature. an agent need not be represented as an agent _locally_. you can optimize things so that there's no difference from functional code. we need to separate abstraction from implelementation. need clever implementation
- ? - mobile agent !-> mobile code
- Gul Agha - yes
- Mudumbai Ranganathan - clean model is nice and aids implementation
- John McKim - look at enterprise java beans server. method of scaling up components. if we had mobile agent execution environment wehere we could specify scal properties (such as ability ot activate things). look at environment so that we can improve scale. we have illusion that things are running, but actually passed out to disk...
- Gul Agha - have need for clever implementations