[ogsa-rss-wg] Re: [ogsa-wg] Teleconference minutes - 2 November 2005

[Karl Czajkowski]

On Dec 12, Donal K. Fellows modulated:
...
> I don't see a major difference, or at least, not until you start having
> nailed-down reservations attached. Without any committed reservations, a
> candidate execution plan is indistinguishable in the case of it being
> issued by an advisory or an authoritative broker. Furthermore, it was
> agreed at the last GGF that neither of the RSS services would cause any
> reservations to be entered into. By that, I mean that no consumption of
> resources would start that could be charged to the user; systems are

OK, it sounds like you are clearly scoped to have "advisory" brokers,
with my definition of authoritative meaning that the selection
response is "what will be allowed", e.g. an obligating decision. :-)

BTW, I was responding to how I read Dave's inquiry about generalizing
the problem, and not specifically to scoping of RSS...


> The other point is that there is no way to stop a resource from going
> away unexpectedly or a client from failing to consume its allocation.
> The resource might get hit by a disaster (natural or man-made), the
> client might die, etc. But this isn't a new problem; it occurs in the
> world of business every day and they deal with it. We should learn from
> them (e.g. by describing the consequences of such failures in terms of
> finanicial penalties) and not reinvent this particular wheel.
> 

Yes, I entirely agree.  I guess it is out of scope though, if the RSS
result is just a list of candidates rather than some obligation of
service.  Filtering and ordering should be sufficient, rather than the
added difficulty of precise monetized (linear) values.


> >   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.
> 
> At the University of Manchester we're looking into these things in more
> detail. At the moment, it looks like the brokering world is going to be
> categorizable into multiple types of service depending on the quality of
> information available. This work is still actively ongoing though, so it
> is a bit too soon to report on it.
> 

Right; as I was trying to describe in response to Dave's question, I
think the boundaries of what is to be accomplished must be set pretty
specifically, because different protocols will be appropriate
depending on the kind of information that can be revealed (and the
sizes of the various data for realistic environments).


> >All interface "refactorings" are not equivalent across protocol
> >boundaries between parties with different authority and trust roles...
> 
> True, but I'm not at all convinced that WS-Ag is quite in the sweet spot
> either. It would help a lot if it was easier to tackle the document
> parts of the spec separately from the service parts because at the
> moment, the sheer size of the overall spec and the feeling that you have
> to read virtually all of it to understand it[*] is scareing some people off.
> 
> Donal.
> [* FWIW, I found I had to read not just the spec but also some of the
>    presentations about it too to understand what was going on. To me,
>    that indicates that the spec document itself has not yet captured all
>    that you intend it to. ]

Yes, public comments have said as much... the problem area is pretty
large, unfortunately, and GRAAP-WG is trying to trim the spec down to
the basic normative aspects.  The group also plans to develop a sort
of primer to provide more useful non-normative introduction to the
approach.  (This was decided because earlier feedback indicated the
specification was too large to digest for people looking for all the
normative bits.)

The difficulty is that the core abstraction of agreement-about-service
is pretty abstract stuff, and the domain-specific examples that can
help illustrate it are definitely non-normative to the base spec.  In
an ideal world, we could present some fully-developed profiles of
WS-Agreement with specific service/resource management domains to
illustrate the base model.  In practice, I think we need to get a
"version 1" out there so that domain profiles can be developed and
usage experience gathered to inform further versions of WS-Agreement.


karl

-- 
Karl Czajkowski
karlcz at univa.com