[GRAAP-WG] Modification to the wiki Page on Renegotiatinganestablished Agreement

Toshiyuki Nakata t-nakata at cw.jp.nec.com
Mon Aug 27 03:25:43 CDT 2007


Karl:
Thank you very much for a detailed comment on the wiki page.
Please give me some time to digest and respond as I am out of cycles right
now:-(

Best Regards & Thank you very much
Toshi
-----
Toshiyuki Nakata 中田 登志之
Executive Chief Engineer, Central Research Lab. NEC
1753, Shimonumabe, Nakahara-Ku,
Kawasaki,Kanagawa 211-8666,Japan
Tel +81-44-431-7653 (NEC Internal 22-60035)
Fax +81-44-431-7609 (NEC Internal 22-60509)
 

> -----Original Message-----
> From: Karl Czajkowski [mailto:karlcz at univa.com] 
> Sent: Monday, August 27, 2007 11:50 AM
> To: Toshiyuki Nakata
> Cc: 'Dominic Battre'; 'GRAAP-WG'
> Subject: Re: [GRAAP-WG] Modification to the wiki Page on 
> Renegotiatinganestablished Agreement
> 
> Toshi, I have the following comments/observations after reviewing your
> wiki page... sorry I have not been able to keep a close watch on the
> recent activities of the group.
> 
> 1. The idea of negotiation of alternatives is difficult and I think
>    requires a better negotiation protocol.
> 
>    After much debate, as I recall, we limited WS-Agreement to simple
>    acceptance of an offer.  If the offer has alternatives in it, then
>    the responder is accepting to satisfy this compound expression in
>    any way he sees fit, with no information about how, or indeed
>    whether his solution might vary over time and be satisfied by
>    different clauses in the compound rules!  It would take
>    domain-specific interpretation of the SDTs to somehow fix this
>    solution, as there is nothing in the protocol to communicate a
>    "lowering" or simplification of the alternatives expression.  (For
>    example, I anticipated that in a basic use of JSDL for a job term,
>    the interpretation could be defined that the service terms are
>    chosen at job-start time and frozen, as is a typical implementation
>    requirement for HPC resources... you would know they are not
>    time-varying, though there is still no facility to communicate
>    which exact parameters were chosen.)
> 
>    What I would suggest is that you try to keep this aspect of
>    negotiation protocol orthogonal to the underlying notion of
>    renegotiation.  First, work on the semantics for renegotiation of
>    an agreement as you have done, e.g. replacement/superceding of an
>    agreement.  Then, admit that basic or advanced protocols could be
>    used to negotiate either the initial or subsequent agreement.
> 
>    For example, a relatively simple renegotiation could adapt the
>    existing factory pattern for both initial and subsequent
>    negotiations.  If a future specification provides a multi-round
>    negotiation to lower/simplify abstract agreement constraints to a
>    more concrete solution, this could replace the basic factory
>    pattern in both cases too.
> 
> 
> 2. I think the idea of superceding an agreement is fine, but I have
>    trouble seeing a distinction between this and the general use of
>    agreements in the context of other agreements.  For example, the
>    advance reservation scenario allows "claiming" of a resource
>    reservation, and you can interpret this as adjusting an initial
>    resource agreement to include binding to an application, with the
>    same results as if someone simply negotiated an application with
>    the same QoS terms in one shot...
> 
>    What I would point out is that this claiming/context model allows
>    many:many derivation of agreements in the general case.  E.g. I
>    could reserve a large resource (in space-time) and consume it with
>    multiple applications which either run serially or in parallel.  I
>    could also combine several resources (in separate agreements) into
>    a complex application.  Couldn't a renegotiation also be temporary,
>    e.g. "boost this resource reservation for the next hour, but then
>    fall back to the previous terms"?
> 
>    I am not sure how "supercededby" would be applicable here.  Is it
>    worth having one more general metalanguage for discovery/navigation
>    of agreements which are linked to other agreements?  We could use
>    the extensibility of the wsag:Context to enumerate the actual
>    claimed or superseded agreements, and it seems useful to have a
>    dynamic resource property which could provide reverse-lookup of new
>    agreements which list an agreement in the new wsag:Context too.
> 
> 
> 3. Also, a general concern I have is that the discussions are not
>    crisp about the uses of the agreement.  The talk of race conditions
>    makes me nervous, as it seems to combine denotation of service
>    terms with the implementation of resource managers.  In my view,
>    WS-Agreement is completely focused on the establishment of terms
>    between the two parties, and says nothing about how one of the
>    parties is implementing the protocol.  I do not see a necessary
>    race condition for "supercededby" because I don't think the
>    initiator (for example) needs to be aware of this state change in
>    order to meaningfully express a claim against an agreement.  If an
>    agreement is renegotiated, it could still be usable for claiming by
>    name, while the actual resource manager has to take into account
>    that there are now aliases to the newly revised delivery terms...
> 
> 
> 4. The question of having "responder initiated renegotiation" was
>    foreseen in the optional symmetric protocol mode. In essence, if
>    EPRs are exchanged so that both parties have an EPR representing
>    the other party's view of the agreement, then they can switch roles
>    and become initiator for further rounds of communication.  In order
>    to use this feature, one would need to define an extension to the
>    protocol, e.g. have the symmetric agreement resources support an
>    extended protocol which includes the renegotiation operations as
>    well as the basic monitoring/cancellation operations.
> 
>    I think it would be appropriate to define a new negotiation
>    protocol as a profile on this feature, so that a specific SDT would
>    demand the presence of a renegotiation facility which would then be
>    available as extended operations and resource properties on the
>    Agreement resource.
> 
>    Again, if we consider the fuzzy case of many:many renegotiations,
>    the best approach might be a simple RP in the agreement that holds
>    an EPR to the renegotiation service, thereby separating discovery
>    (via lookup of this RP an existing agreement) from claiming/context
>    references which might involve more than one agreement at a time.
> 
> 
> karl
> 
> 
> -- 
> Karl Czajkowski
> Software Architect
> 
> Univa Corporation
> 1001 Warrenville Road, Suite 550
> Lisle, IL 60532
> 
> karlcz at univa.com
> www.univa.com
> ________________________________________________________________
> www.univa.com.
> 
> The Leaders of Open Source Cluster and Grid Software
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4038 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070827/71449c5b/attachment.bin 


More information about the graap-wg mailing list