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

[Toshiyuki Nakata]

Michael:
Thank you very much for a thorough introduction 
of the current art.

As Omer says, I'll also study some of the documents which 
I had not known before..



-----
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: Michael Parkin [mailto:parkinm at cs.man.ac.uk] 
> Sent: Friday, August 24, 2007 5:36 PM
> To: Toshiyuki Nakata; Dominic Battre
> Cc: GRAAP-WG
> Subject: Re: [GRAAP-WG] Modification to the wiki Page on 
> Renegotiating an established Agreement
> 
> Toshi, Dominic,
> 
> As no-one else has replied...
> 
> On 23 Aug 2007, at 15:30, Toshiyuki Nakata wrote:
> 
> >> 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.
> 
> A 2PC-type protocol works well when you control everything. However,  
> where autonomous services are involved in (possibly) different  
> administrative domains (such as in a business environment) the cons  
> of using the 2PC style in agreements like this are well understood,  
> for example:
> 
> * Skeen's paper [1] on commit protocols describes why 2PC is a  
> blocking protocol.
> 
> * Pat Helland (formally Amazon, now Microsoft) describes the 2PC  
> protocol as the "anti-availability protocol" [2] because of the fact  
> it can block the transaction manager (Dominic, this would be the AR  
> in your protocol). As he says: "[2pc] is best used sparingly".
> 
> (Toshi - I also direct you to his article on "accountants don't use  
> erasers" [3] about why agreements should not be overwritten).
> 
> * Mark McKeown also has a blog article [4] about the difficulty of  
> distributed consensus, which is essentially what you're trying to  
> achieve (FTA: "consensus was originally called agreement").
> 
> * If you want a lighter read the Wikipedia article [5] also 
> discusses  
> 2PC's blocking.
> 
> About the Mobach, et. al. paper [6] - the last three steps in Figure  
> 2.4 are a 2PC-type protocol. When the 'DC' (from the paper) returns  
> the 'agreement offer' to 'A' they are blocked from offering those  
> resources to anyone else (although this is an assumption because the  
> paper doesn't say explicitly what the 'agreement offer' 
> actually means).
> 
> Imagine the scenario: DC returns an offer to A1 saying 'these  
> resources for €10". Meanwhile A2, who is prepared to pay €10,000 for  
> the same resources cannot make the agreement because DC has offered  
> them to A1. A2 then goes and makes an agreement with another 
> DC (e.g.  
> another business) and A1 decides they don't want the resources and  
> return a reject message. DC has lost €10,000 of income it could have  
> made because of the protocol it is using.
> 
> If A1 is a proxy for a competitor of DC it could repeatedly keep  
> asking for offers it never intends to agree to meaning DC may loose  
> revenue...
> 
> Dominic: before I comment further on your proposed protocol what  
> semantics are you attaching to the 'offer' message that the AR  
> returns to the AI? Does the offer mean 'if you accept I will  
> guarantee providing what is contained in this offer' or does it mean  
> something else?
> 
> Michael.
> 
> [1] http://www.cs.cornell.edu/courses/cs614/2004sp/papers/Ske81.pdf
> [2] http://blogs.msdn.com/pathelland/archive/2007/05/20/soa-and- 
> newton-s-universe.aspx
> [3] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants- 
> don-t-use-erasers.aspx
> [4] http://betathoughts.blogspot.com/2007/06/brief-history-of- 
> consensus-2pc-and.html
> [5] http://en.wikipedia.org/wiki/Two-phase_commit
> [6] www.iids.org/publications/scpe06.pdf
> 
-------------- 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/e80831d7/attachment.bin