[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