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

[Omer F Rana]

Hi Michael,

Thanks for these excellent references -- will be downloading and reading them. 
My undersstanding of the Mobach et al. paper -- and  the reason the 2PC
approach was chosen was to satisfy legal constraints that they were working on. 
Their aim was more to ensure that legally both parties were covered, more than
looking into the specifics of constraints of a distributed implementation. 

I am copying David Mobach and Benno Overeinder. 

regards
Omer


On Fri, Aug 24, 2007 at 10:35:50AM +0200, Michael Parkin wrote:
> 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
> 
> --
>   graap-wg mailing list
>   graap-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/graap-wg

-- 
http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598
work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative
computing / room n2.14 / school of computer science / cardiff university 
  queen's buildings / newport road / cardiff cf24 3aa / wales / uk