[ogsa-wg] Teleconference minutes - 2 November 2005

[Karl Czajkowski]

Dave, I think the interesting point of collision with "candidate set
generation" and "planning", e.g. traditional scheduling, is when you
consider non-trivial QoS regimes.  For example, when services do not
give best effort service to all callers, and you cannot just assume
statistical averaging to predict future service based on past, etc.

Then, there is a significant difference between a scheduler or broker
who returns advisory information and one who returns authoritative
information.

In the advisory case, he is essentially a discovery service helping
you locate services with nice properties observed in the usefully
recent past.  However, until you act on that information by attempting
to acquire service, you have no idea whether the service is actually
nice or not for your goals.  He may be suddenly congested, or have
differentiated policies which make your request impossible to
fullfill despite his overall nice status.

In the authoritative case, the scheduler actually has some control
over those remote services, i.e. (part of) their capacity is reserved
to be used at his discretion.  In this case, he can actually
determined when and how much service you should obtain, and inform you
of a stateful adjustment to his overall resource plans that includes
you.

There might be protocol differences to support these cases, e.g. an
authoritative answer might carry some rights assertion that you can
present to the service, or the broker may have to go update remote
services behind the scenes but before you manage to contact them.
Also, the authoritative broker may demand that you "decline"
allocations he has issued you, while you can presumably walk away from
an advisory information source since no stateful allocation has been
made.

I do think you are on the right track to call a ranking function
"policy", and in non-trivial scheduling regimes I think you will
always have to present such policy rather than being able to obtain a
sufficient picture of the environment to make decisions yourself.
This is because of several things:

   1. You will not get an atomically consistent view of the environment
      to act on, while the remote manager may have such a mechanism.

   2. You will most likely not get a complete picture of the future
      service allocation plans, in the event of advance reservation.
      It would be too much data to exchange for each request; it might
      include confidential information; and it might not be clearly
      separable from the scheduling algorithm that might include
      statistical approximations and/or other hueristics.

   3. You will not get a complete picture of the differentiated polcicies
      that different brokers or services apply to specific individuals,
      because it may be confidential and is also meaningless without a 
      global view of other competing activities.

Thus, I think a significant step of ANY distributed planning exercise
with non-trivial QoS will be the sort of handshake captured in
WS-Agreement: make an "offer" bearing policy expressions that describe
what you want; allow the authoritative resource manager to consider
this offer among others and its stateful policy and resource
availability models; obtain an answer of whether the manager can
arrange services according to your offer; and (optionally) introspect
to find out HOW the manager will provide you service.

All interface "refactorings" are not equivalent across protocol
boundaries between parties with different authority and trust roles...

(More specific comments inline.)


On Dec 10, Dave Berry modulated:
...
> One factor that influences this choice might be who has the access to
> the necessary information.  If the client has privileged information
> that should not be made public, then the choice might have to be made by
> the client; or the framework should encrypt the policy parameter and
> provide a trust relationship with the selection service.  Conversely,
> the client may want to see only an abstraction of the detailed selection
> process.
> 

Right, I think it is critically important to find out the nature of
the roles here before trying to design a protocol.


> If we have parameterisation, then the question arises of how expressive
> a language we need to specify the parameterisation.  Do we need a
> general-purpose programming language (e.g. Python script) or will the
> draft WS-Agreement language be sufficient?  
> 
> The replies I received suggested both that the parameterisation would
> require a general programming language and that the client may have
> privileged knowledge that it does not wish to share, and therefore it
> would be better to leave decisions to the client.  I'm rather sceptical
> of the first point but it would be good to examine real systems to
> determine what is really needed.
> 

Just a reminder: one often-discussed "trick" for handling such
isolation of data and abstraction is to allow delegation of resource
management authority.  An explicit advance reservation interface can
abstract away the application goals (and confidential information) to
describe required capabilities.  The remote manager can schedule and
allocate a solution to these without understanding the application,
policy permitting. The result of the reservation is a new "virtual
resource" and a policy giving the client-side manager authority over
it. Then, the client-side logic can perform the fine-grained planning
of that resource capability for its specific application functions,
revealing only the minimum operational information.


> There are clearly many possible answers in this space - which brings us
> back to Ian's list of schedulers.  One question might be whether we can
> identify an interface, or a small number of interfaces, that generalises
> a significant number of practical use cases.
> 
> Best wishes,
> 
> Dave.
> 

karl

-- 
Karl Czajkowski
karlcz at univa.com