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

[Benno Overeinder]

Hi Omer and Michael,

Maybe late, but here is my 2 ct. contribution to the discussion of  
the 2 phase commit protocol used in our extended WS-Agreement  
implementation.

I agree with Michael's analysis of the fundamental problems with 2PC  
in its blocking behaviour.
Indeed, the cited references give a good overview of the problems  
with 2PC.  The other argument of missing revenue when two offers  
arrive just after each other: while processing the 10 euro offer, the  
10,000 offer might be rejected (by short of resources), and  
eventually the 10 euro offer is not committed.  I think this problem  
is not specific to our approach, with any negotiation/obligation you  
can miss revenues if better offers, while engaged with a partner who  
might bail-out.  Do you know of other negotiation strategies/policies  
that does not suffer from this?  We can solve this in our framework  
by supporting re-negotiation, if a better offer arrives, the resource  
owner can start a re-negotiation with the current resource users.    
The problem of a denial-of-service attack (by proxy) is serious in  
any system where resources are allocated to the (un-) successful  
negotiation process (either by reserving resources or the use of  
computing resources by the protocol itself).  In the paper, we did  
not include the details of authentication and trust, but this is  
included in the implementation of the framework.  Repeated malicious  
behaviour will be punished and requests will not be considered.

We chose to use 2PC, as it is a simple extension to the WS-Agreement  
protocol (and can be made compatible/interoperable by just skipping  
the last two steps).  We did not want to redesign the WS-Agreement  
protocol, but include some primitive means for negotiation other than  
one-shot negotiaton (think of contractNet), and both parties commit  
to an agreement for legal purposes (as Omer explained).   I will  
definitely look into your work with Dean Kuo.


On Aug 24, 2007, at 1:09 PM, Omer F. Rana wrote:

> Hi Michael,
>
> Yes, I off course agree with your statement that all three must be  
> taken
> into consideration. In practice, many
> implementations do not follow this line however -- but they should.
>
> I guess there is a trade off between making the protocol too  
> complex --
> so much so that no one will actually
> use it -- vs. making it complete -- so that it takes account of
> everything that is useful. But you are right.
>
> Thanks also for the additional links. Seems like I have my reading set
> out for this w/end.
>
> regards
> Omer
>
> Michael Parkin wrote:
>> Hi Omer,
>>
>> Thanks for your reply.
>>
>> On 24 Aug 2007, at 10:53, Omer F Rana wrote:
>>
>>
>>> 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 believe that the legal, distributed computing _and_ business
>> aspects of agreement must be considered together to design a
>> successful contract negotiation and formation protocol - they cannot
>> be considered separately. When all three aspects are taken into
>> account together it is clear that 2PC-type protocols are
>> inappropriate for cross-administrative domain negotiation because of
>> the risk of blocking that is introduced, as I described in my
>> previous email.
>>
>> Work we have done [1] together with the School of Law at Manchester
>> University investigates maintaining the legalities of contract
>> negotiation and formation (including adhering to the EU's e-Commerce
>> directive) whilst still allowing the entity supplying the resources/
>> services not to be blocked, thus satisfying the requirements of
>> business. Section 4.1 of the linked paper discusses blocking.
>>
>> Dean Kuo (who many of you know...[2]) and I are writing up and
>> formally specifying the protocol we derived from this work and will
>> be submitting this work for publication soon.
>>
>> Michael.
>>
>> [1] http://www2.cs.man.ac.uk/~parkinm/publications/
>> eChallenges_e2006_ref_235.pdf
>> [2] http://www.cs.man.ac.uk/~dkuo/
>>