[GRAAP-WG] Feedback on "Challenges in EU Grid Contracts"

[parkinm at cs.man.ac.uk]

Hi Karl,

Thanks for taking the time to read our paper. 

On Aug 27 2007, Karl Czajkowski wrote:

> Michael, I just read "Challenges in EU Grid Contracts" for the first
> time after seeing it linked from Toshi's wiki page updates.  I thought
> it might be useful to address several topics in the paper regarding
> WS-Agreement, though I have a suspicion that some of these issues may
> have been addressed long ago by others...

Maybe they have been addressed long ago, but they aren't clear (to me 
anyway) from the spec and as someone who wasn't involved in the 
specification process.

> 1. There is an assertion that WS-Agreement does not support
>    acknowledgement of receipt of an offer independent of the
>    acceptance decision.  This is incorrect, as the PendingAgreement
>    construct is specifically defined for this purpose: the
>    CreatePendingAgreement factory pattern returns an EPR to a
>    PendingAgreement which is yet to be accepted or rejected.
> 
>    This feature was motivated by a different observation that a
>    decision process might be too slow to perform during a
>    SOAP-over-HTTP in/out message, but it equally addresses your
>    concern of knowing that the offer was received before the decision
>    process is complete. (A WS-* purist position could be that message
>    acknowledgement is a transport-level problem rather than a SOAP
>    problem, but we had to bow to the practical use of
>    SOAP-over-HTTP...)

Yes, I agree. The pending state (though personally I think 'received offer' 
is clearer) can be used to run tasks scheduling algorithms, for instance, 
like our paper says.

However, I don't think a message acknowledgement (in its most general 
sense) is "a transport-level problem" (I'm not sure if you were agreeing or 
disagreeing to this point and what your reference to SOAP/HTTP means - it 
isn't clear).

For example, how do I know that a service didn't crash between the 
transport-level message being accepted and the application processing it?

Therefore in this scenario the application-level - not the network-level - 
must acknowledge message receipt (when acknowledgements are used).

> 2. There is an allowance for external acceptance notification
>    channels, though I admit this is not emphasized in the
>    text. Present in the base protocol are the Acceptance port type and
>    the agreement state resource property, both of which may be used
>    simultaneously on the same agreement. It is the state model which
>    allows for transitions to accepted state independent of the other
>    protocol operations.  There is nothing to disallow other
>    notification paths such as email, facsimile, registered mail, etc.
>    (but, see next issue).
> 
> 3. A significant difference between WS-Agreement and the contract law
>    model described in the paper is the moment of acceptance: in
>    WS-Agreement, acceptance is defined as the moment the responder
>    chooses to accept, and is not dependent on sending an acceptance
>    message to the initiator.  This difference becomes clear in unusual
>    asynchronous/lossy message environments and/or contested
>    agreements.

Yes, and since the publication of this paper we have learnt that this model 
of acceptance is also valid in contract law. It is called the 'mailbox 
rule' and (in a nutshell) says that as soon as the offeree 'posts' their 
acceptance the contract is made. Though it must be stated in advance that 
this is being used and not the traditional method we described in our 
paper. The protocol we are writing up uses the 'mailbox rule' model because 
(if the offeree was the service provider) it leads to the resources the 
contract is being made for being 'locked' - which I think we agree is an 
unacceptable situation - until the service provider knows the accept 
message has been received.

>    This is a crucial technical point in WS-Agreement. In order to
>    define the acceptance moment as when the acceptance is delivered to
>    the initiator (as in your contract law discussion) would require a
>    reliable delivery model where some trustworthy (third-party)
>    observer can witness the delivery.

No, not necessarily. Note that business (generally) operates quite well 
without third-parties and often uses unreliable messaging to form 
contracts. There is also a well-known example (in legal circles, anyway) 
used to illustrate the loss of acceptance messages where the mailbox rule 
is not being applied, i.e. when acceptance is delivered to the offeror. It 
does not require a "reliable delivery model" or "a trustworthy observer" to 
be in place.

The legal example, using the more correct terminology of 'offeror' and 
'offeree' in place of initiator and responder, is as follows and should be 
understandable when applied to a distributed computing environment. The 
offeree shouts an acceptance message to the offeror. Just the offeree does 
so a plane passes overhead and the offeror does not hear the acceptance 
message (i.e. it is lost). The legal position is that it is upto the sender 
of the message to make sure the acceptance message gets through. Thus, the 
offeree keeps sending the message until they know it is understood.

But, as you point out below, the offeror may choose to ignore (or claim not 
to receive) the accept message. However, because of the semantics of an 
offer, the offeror is bound to its contents if accepted so there is also an 
responsibility on the offeror to make sure they know the status of any 
offer that they make (and not make offers they do not intend to fulfil). 
The semantics of the message are critical in this protocol - hence my 
question to Dominic in my original email about the meaning of his 'offer' 
message.

There are also other rules in contract law that help deal with this 
situation.

The meaning of an offer (along with the experience gained over many years 
of forming contracts in distributed environments gathered by the legal 
community) makes the protocol inherent in contract law 'work': once an 
offer is made the offeror cannot walk away or choose not to take part if 
the offeree accepts that offer - even if they don't get the accept message.

An offer is binding, unless it has been revoked. Therefore the offeror 
should always want to receive the accept so they can plan/reserve funds/do 
whatever they need to do - even if it is to ask that the contract is 
terminated immediately - as part of their side of the contract. If they 
don't then they will be at risk of breaking the contract and liable to the 
penalties therein.

>    At risk of confusing the terminology, a way to characterize such a
>    variant of our protocol might be:
> 
>    1. initiator sends offer to responder.
> 
>    2. responder chooses to accept.
> 
>    3. responder attempts to send acceptance notice.
> 
>    4. reliable message channel observes delivery of (3) and acceptance
>       is now true.
> 
>    Given our presumption of an Internet-like environment without any
>    secure, third-party channel to "serve" notices, this does nothing
>    more than "rotate" the participant roles by one unidirectional
>    message.  In effect, it is really the "initiator" in step (4) who
>    decides acceptance by choosing to receive the acceptance notice or
>    not, because it is not possible to prove that he received a message
>    unless he acknowledges it!  

I agree, this is why we use the 'mail box' rule as otherwise we get into 
evidential issues about how many times the accept was attempted to be 
delivered, etc. But the offeror is still contracted whether they like it or 
not.

> Thus, his offer is not really
>    obligating, as he can shirk his responsibilities by choosing not to
>    acknowledge the acceptance.

About "his offer is not really obligating". How so?

An offer is binding/obligating once made (again, unless revoked) therefore 
by "shirking their responsibilities" they may be breaking the contract and 
open to recourse.

If it's not an offer then the offeree cannot accept it. 

The message must be an offer/not be an offer. It can't be a non-obligating 
offer, in that case it would be something else.

>    Thus, I would say the above "contract law"-style sequence of:
> 
>       offer/accept/receipt-as-decision 
> 
>    is indistinguishable in practice from:
> 
>       invite/offer/accept-as-decision
> 
>    As there must be some party in the system that first knows the
>    decision before this information is distributed asynchronously to
>    all parties, we make the responder be the observer! 

Yes, contract law has an inherent bias towards the offeree who knows the 
decision first and is what (I think) you're saying. In a distributed system 
there will always be a lack of consistency somewhere (unless you sacrifice 
availability).

A side question: what do you mean by "this information is distributed 
asynchronously to all parties". I thought WS-Agreement was 1:1 and the 
acceptance by the offeree only had to se sent (or made available) to the 
offeror? (i.e. one party). What "other parties" do you mean?

>    Finally, as I
>    described it in a previous email.  WS-Agreement supports this
>    through the slightly more general:
> 
>       advertise/offer/accept-as-decision
> 
>    where you could restrict or otherwise optimize access to
>    advertisements in order to effect a directed invitation.  (It is
>    considered somewhat out of scope for WS-Agreement to define how
>    advertisements are retrieved, e.g. what sort of publishing or
>    information dispersal architecture is used for discovery.)
> 
> 
> I hope this helps clarify the technical solution embodied in
> WS-Agreement.

Thanks for taking the time to privide these clarifications. However they 
don't address the other question of the resource provider having to 'lock' 
it's resources in a 2PC-style when it makes an offer, as was also discussed 
(and a solution proposed) in our paper.

Thanks again,

Michael.