[rideau@clipper.ens.fr: Re: Migration policy]

[Raul Deluth Miller]

I'll post my response to the list myself -- Raul

Return-Path: <rideau@clipper.ens.fr>
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Subject: Re: Migration policy
To: rockwell (Raul Deluth Miller)
Date: Fri, 16 Dec 94 20:19:09 MET
In-Reply-To: <199412161850.NAA26816@nova.umd.edu>; from "Raul Deluth Miller" at Dec 16, 94 1:50 pm

>    * before you actually migrate, you allocate the resources, so that no
>     uncontrolled massive migration waves are done on systems.
> 
> I think that being capability driven will do away with the need for
> this kind of hack.
   Uh ? What's that ? I thought we agreed being able to see is being able
to access. The pointer is the capability. So what exactly do you propose ?
   I mean that so that an unloaded machine would not be overflown with
migrating objects, it would have to accept any object and allocate all needed
resources *before* the object is actually migrated. That is, never migrate
an object that may have to be bounced back or away. Note that this does not
forbid gates to exist and try to migrate objects to farther networks.


>    * systems are (dynamically) hierarchically organized with each time
>     more global resource servers.
> 
> I'm not sure of the significance of this one.
   I meant that to reduce traffic, networks can organize in trees, so that
the migration decision process is simplified and accelerated.


>    * only profiled objects (which can be done dynamically and/or
>     statically) may be migrated, so that we may compute the effects of
>     migration on load (because migration involves both pointwise and
>     continuous communication bandwidth).
> 
> I think this one needs more analysis before we can talk about specific
> policies.  Basically, we're going to be involved in protocol design,
> which is rather different from the kinds of work I've seen discussed
> on this list.
Our project is rather large; this kind of work must be done too...


>    * you try to migrate objects that communicate heavily to machines
>     that would reduce communication overhead.
> 
> This looks like more protocol design.
What I meant is you must bring nearer objects that cause heavy network
load. e.g. if you have some filter to question a far database, you'd better
run it near the database...

> For a large scale system, there need to be some objects which tackle
> issues like getting things going, spotting/clearing problems,
> optimizing communications, configuring new machines, etc. etc. etc.
> Ideally, at least a third of our work is going to non-management work
> (which is a lot better than you can say of lots of single-user
> systems).
Yes. We need some extensible scheduler/optimizer.


>    * you don't accept unsecure migrating foreign objects.
> 
> lightly loaded machine can reject work.  [Raise a red flag when this
> happens -- it indicate's something's gone wrong.]
Nope. If rejection is due to lack of resource, it happens before the
originator sent the object, so nothing is to go wrong in that case.
But yes, we must have some protocol so that nothing gets wrong: we
need keep an object in good state until it was successfully acknowledged
by the remote (trusted) host, and prehaps even after, if the host is not
trusted enough.