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

[Toshiyuki Nakata]

Karl:
thank you very much for the excellent summary.
(which I must  admit I would need a week to really digest.).

One thing that I (and I think you also pointed out ) was that that 
in the case of AR not agreeing, there were not enough hints
for the AI to initiate another request..

Any comments on this?

#Also comments to show stopper #7 would be very much appreciated :-)

Best Regards
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: Friday, August 24, 2007 6:55 PM
> To: Toshiyuki Nakata
> Cc: 'Dominic Battre'; 'GRAAP-WG'
> Subject: Re: [GRAAP-WG] Modification to the wiki Page on 
> Renegotiating anestablished Agreement
> 
> On Aug 23, Toshiyuki Nakata modulated:
> > Hi Dominic:
> > > So, yes, there are problems but it looks like a lot of 
> people want to
> > > have this extra commit message. Are there any written 
> records on the
> > > pros and cons of having the 2PC?
> > 
> > I think this info. is very important.
> > Unfortunately, I am not able to address this issue.
> > 
> > Karl or others, please respond..
> 
> I definitely don't want to repeat the debate which is in the GRAAP-WG
> email archives, but let me just summarize what I think were the final
> observations and conclusions.
> 
> WS-Agreement is aimed at a distributed, soft real-time (one might say
> isochronous) environment with limited trust between peers with bounded
> rationality.  In other words, it is for establishing automated
> agreement between programmatic systems in an Internet-type environment
> where the agreement terms may involve wall-clock obligations which are
> at the root of the problem.
> 
> When you boil it all down, there is always going to be a
> synchronization hazard where due to communication delays or faults, or
> even intentional decision delays, one party does not know whether the
> other has accepted the agreement and therefore is at risk to perform
> according to the terms of agreement when not necessary, or ignore the
> terms of agreement when bound by them.
> 
> WS-Agreement formalizes this hazard to always place the burden on the
> agreement initiator who makes an offer and is bound by it if the
> responder accepts.  Early drafts, derived from our SNAP work, had an
> extra signalling step to allow a sort of "pre-initiator" called an
> invitation.  The group felt that this was too complicated to pursue,
> particularly because it could be approximated via advertisement.
> 
> An invitation or advertisement would be a non-binding expression of
> interest in receiving agreement offers, so that the typical
> client-server roles could be reversed somewhat.  The only difference
> is that an invitation is seen as usually a 1:1 relationship while an
> advertisement is 1:many. However, due to the non-binding nature of
> these signals and the assumption of bounded rationality (we can ignore
> the possibility of bluffing and other psychological strategies), I am
> not sure these differences are significant.  For privacy, one could
> imagine secure advertisement channels (with authorization) to further
> blur the boundaries.
> 
> Furthermore, 2PC can be synthesized with two WS-Agreement round-trips
> and an appropriate domain-specific agreement semantics. So, either
> advance reservation, combined with the right cost/penalty model, or
> the underlying invitation system can both look like 2PC in practice:
> 
>  1.a.  initiator offers advance reservation, OR
>  1.b.  advertiser publishes interest
> 
> after this first stage, both parties are aware of interest and primed
> to negotiate...
> 
>  2.a.  responder accepts (or rejects) reservation offer, OR
>  2.b.  initiator offers against advertisement (or ignores it)
> 
> after this stage, one party is obligated to satisfy and the other has
> a choice to make... (For the advance reservation, the initiator has a
> choice because the reservation includes a cost model with cheap
> cancellation under reasonable deadlines).
> 
>  3.a.  initiator offers claiming agreement (or cancels 
> reservation), OR
>  3.b.  responder accepts offer (or rejects it)
> 
> after this stage, both parties are obligated to satisfy...
> 
>  4.a.  responder accepts claiming agreement (or acknowledges 
> cancellation), OR
>  4.b.  initiator acknowledges receipt (e.g. transport-level ACK)
> 
> after this stage, both parties actually know what the other knows...
> 
> In case it isn't obvious, advertisement is done via WS-Agreement
> templates and advance reservation followed by claiming is anticipated
> in the usage scenario examples as well.
> 
> 
> > Best Regards
> > 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)
> >  
> 
> 
> karl
> 
> p.s. I will add that the fundamental challenge I see for GRAAP-WG and
> WS-Agreement is that everyone approaches it with the same natural (but
> incorrect) intuitions about trust, signalling, and consensus.  I think
> there is still a large social experiment to see who can deploy systems
> which are actually performing distributed agreement without a central
> authority... economics and our real-life world says it should work,
> most of the time at least. :-)
> 
> -- 
> 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/20070824/8f66b2a6/attachment.bin