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

Michael Parkin parkinm at cs.man.ac.uk
Fri Aug 24 03:35:50 CDT 2007


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




More information about the graap-wg mailing list