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

[parkinm at cs.man.ac.uk]

Hi Karl,

On Aug 28 2007, Karl Czajkowski wrote:

> > For example, how do I know that a service didn't crash between the 
> > transport-level message being accepted and the application processing 
> > it?
> 
> What difference would it make? :-) Is there some difference between
> crashing after the transport ACK or the application ACK?  

A lot and yes. A transport ack doesn't tell me the application recieved or 
was able to understand the content, for instance.

> You seem to
> be assuming that the application is somehow more trustworthy than the
> transport to buffer/persist a message until application restart can
> make progress.  This is an implementation choice that is not captured
> at all in the WSDL, but in the endpoint software stacks and the SOAP
> bindings that are in use...

What about server/container crashes? AFAIK TCP doesn't have a persistent 
buffer to protect against server crashes and most containers don't 
(natively) support message persistence unless you use a MOM.

In this case, why not design the protocol so that it can handle these 
situations rather than specifying how it should be implemented?

> > 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.
> 
> I think you are bringing in some of those intuitions I warned
> about... your legal example works because of a presumption of courts
> and evidential proof of due diligence etc.  

WS-Agreement is going to be used where these institutions don't exist? Any 
resource provider (read business) potentially charging for work can't do 
this in splendid isolation of the existing local regulations and law...

> We could not readily
> assume such an environment for resolving WS-Agreement negotiations,
> since audit systems and legal systems are not within scope of the
> GRAAP-WG. 

I agree about the audit systems as this would be dependent on the local 
regulations where the service is being provided from.

But, taking into account consideration the impact on business could be 
considered as being in scope if WS-Agreement is to be used between 
businesses (or individual users and businesses).

One of the documents that got me interested in this topic was [1], where it 
states: "[agreements for Grid resources] present a formidable challenge, 
not least because of different international legal frameworks within which 
they have to operate" - others also recognise it can't be ignored.

> We just toss up our hands and say one party is at the mercy
> of the other party sending notice of the decision.  

As I've said before - the offeree always knows the decision before you. It 
isn't a question of throwing your hands up - this is how it is, therefore 
the offeror must be sure that they a prepared to enter into the contract 
when they make the offer.

> It becomes a
> separate quality of implementation or trust issue for offerors to
> choose offerees.

Of course, but how do you stop the bad guys? If there are no courts or 
we're outside the legal system (like you mentioned above) who's going to 
take care of them?

> This was important in order to provide a stepping stone for existing,
> traditional resource managers to be updated with WS-Agreement. The
> underlying offer/accept handshake and decision bias is very much
> consistent with conventional job-submission systems.  We were also
> focused on relatively frequent (and automatic) real-time negotiation,
> i.e. the job and transient network QoS usage scenarios that motivated
> the GRAAP charter and its predecessors in the GARA and SNAP work. I
> think concerns about legal status and financial obligations took a
> back seat to concerns about practical distributed resource management.

As I said in another email, I believe that the legal, distributed computing 
and business aspects all need to be considered together. I also said that I 
think a simple protocol that meets these requirements is achievable.
 
> All the same, I think our solution MAY be applied soundly in an
> environment where more audit and legal rules are available to resolve
> conflicts in retrospect. We took pains to provide the runtime
> extensibility handling so that profiles/extensions could be defined
> for things such as digital signature of offers and acceptance messages
> (early public comments worried about getting digital signatures for
> non-repudiation, and we tried to enable this without making it
> mandatory for traditional Grid use cases).
> 
> > 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.
> 
> If the obligations can be contested based on "how many times the
> accept was attempted to be delivered, etc.", then what does it mean to
> say the offeror is "contracted"? (I ask this only out of academic
> interest, since you have already advocated the mail box rule.)

"What does it mean to say the offeror is contracted"? That they are bound 
to their obligations in the contract.

I don't think the offeror would be contesting the obligations though, after 
all they sent them to the offeree. If they made a mistake and the offer was 
accepted - tough. (Like I said before, the offeror better be prepared to 
enter into a contract based on the offer they send).

I presume that what you think may be contestable is whether the contract 
was actually formed or not if the agreement was never recieved. I think 
we've covered this.

> OK, I'll accept this tautology and rephrase my statement to say that
> there is a practical ambiguity in whether the message is an offer or
> not, if one is not using the mail box rule, due to the ability for the
> initiator to pretend not to receive the acceptance.

If there's a 'practical ambiguity' between telling the difference between 
an offer and not-an-offer, then how do you tell the difference between any 
messages?

If the message semantics/schema are defined and agreed to then you should 
be able to tell the difference and there is no practical ambiguity. If you 
haven't defined the semantics/schema (or have only partially defined them) 
then how can you interoperate at all?
  
> > 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.
> 
> I am not sure I know what question or solution you mean here.  

See the original discussion on 2PC being a blocking protocol.

> All I see in my reading of the document is a statement that a resource
> provider should be the offeree to avoid live lock.  Is this what you
> mean?

Yes, the resource provider should always be the offeree to avoid locking 
its resources until it knows the other party is willing to make a contract 
for those resources. It avoids any possibility of a denial-of-service 
attack on the resource provider.

> WS-Agreement defines the initiator/responder roles (offeror and
> offeree as you say) and is silent on resource provider/consumer roles
> because these concepts are inherently domain-specific. 

I don't agree - generally, this is domain-independent precisely because the 
supplier or provider won't want to commit their goods before they know they 
are being sold. It also gives them the opportunity to say 'no' in case they 
have made a mistake or want to offer them to someone else. I say generally, 
because this may happen but it's a marginal case. Can you give me some 
examples where the offeror is the supplier/provider?
 
> Your example in the document has a (to my eye) unusual scenario where
> a user "asks for a quote" and the computing service makes the offer.

Our e-Challenges paper? If so, then this example ("computing service makes 
the offer") is used to illustrate why computing services shouldn't make 
offers - we weren't advocating it!

Also, if "the computing service mak[ing] the offer" is an "unusual 
scenario", why does the protocol Dominic wrote up from your emails [2] 
describe this very situation? (Step 5).

> This is something we could have handled in SNAP via our invitation
> message, but the GRAAP-WG intentionally removed this capability.  As I
> described in an earlier email, one could approximate this through a
> sophisticated use of advertisements (templates) and some template
> exchange system, but I think it is safe to say we marginalized this
> use case.

I'm interested to know why this is a marginal use case for GRAAP-WG. I feel 
it is central in any agreement process in order for both parties to let the 
other know what they want/are providing without issuing any binding offers.

I also believe it doesn't have to be "sophisticated" - eCommerce web sites 
(i.e. distributed Internet-based services selling finite resources) seem to 
do quite well with web pages.
 
> Interestingly, we found that there are differences of opinion as to
> what the "resource" is in some concrete examples! 

In my opinion a resource can be anything that can be traded. Time, money, a 
book, a house...

> It really depends
> on the domain, market, and community as to which aspect/role of the
> SLA is the more rare resource worth optimizing.  If we assume that
> SLAs are about exchange of resource/service, the question is whether
> one party has a worse opportunity cost in obligating their resource in
> exchange for the other party's resource.  If so, it would be
> preferable to allow the party with the worst opportunity cost to act
> as the offeree.

Sorry, but what does "worst opportunity cost" mean? Please, in a couple of 
sentences :-)

Michael. 

[1] ftp://ftp.cordis.lu/pub/ist/docs/grids/ngg3_eg_final.pdf
[2] https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit