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 mobility's use

the level of technology - mas, mob code

• how do we design general purpose mechanisms?

  application perspective

• how do we structure an application to meeting requirements of scale and ft?

  two views are tightly coupled. they affect each other

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, workflow

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

fault tolerance

concentrating interaction locally as opposed to spread

relocating computation

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 itself!

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

• exactly once, atomicity

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 in systems

    heavyweight systems
    

    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