Feedback on "Challenges in EU Grid Contracts"
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... 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...) 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. 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. 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! Thus, his offer is not really obligating, as he can shirk his responsibilities by choosing not to acknowledge the acceptance. 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! 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. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software
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.
On Aug 28, parkinm@cs.man.ac.uk modulated:
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).
There are multiple schools of thought on web service messaging, and I am not sure which school I belong to. :-) SOAP is a transport agnostic standard which has been conventionally applied with HTTP transport but could just as easily be mapped to SMTP, local procedure calls, a reliable message queueing system, or any other message-bearing infrastructure. It becomes murky because many of the arguments assume certain other software engineering practices in addition to the standards themselves. For example, there are those who want to separate the basic content-bearing messages, e.g. the abstract offer-accept protocol, from the implementation, e.g. offer-as-SOAP-over-HTTP or offer-as-SOAP-in-reliable-message-queue. There is nothing in the WSDL for a protocol which says that an in/out (RPC-style) message exchange has to occur in any particular amount of time. A year-long asynchronous offer-accept exchange could be represented in a single SOAP in/out message pair, if the transport bindings were chosen appropriately to allow reliable routing and processing of the messages. At the same time, the layers of abstraction are expected (by most people) to leak on occasion, e.g. the application becoming aware that a TCP/IP error prevented the SOAP-over-HTTP message delivery, or the reliable message queue taking responsibility for the message so the sender does not have to attempt retry etc.
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? 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... In any case, I am not advocating one view or the other, but trying to provide background on why the mixture of approaches has been defined in WS-Agreement.
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.
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. 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. We just toss up our hands and say one party is at the mercy of the other party sending notice of the decision. It becomes a separate quality of implementation or trust issue for offerors to choose offerees. 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. 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.)
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.
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.
A side question: what do you mean by "this information is distributed asynchronously to all parties".
I was thinking of the co-allocation scenario where multiple SLAs are being formed with different providers. The initiator (in the advance reservation case) is acting as the coordinator to obtain multiple advance reservation SLAs (to prepare) and then obtaining matching claim SLAs (to commit) if he decides to go forward with the entire transaction.
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. 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? 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. However, in our example of a job system, we illustrate the use of JSDL-based terms for a client to make a job offer that the computing scheduler can accept or reject. This is our expected idiomatic application of WS-Agreement, which matches your preferred scenario. 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. 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. Interestingly, we found that there are differences of opinion as to what the "resource" is in some concrete examples! 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. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa Corp. and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address.
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
On Aug 29, parkinm@cs.man.ac.uk modulated:
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...
My point was rather that we expect these audit and legal issues to be "mixed in" by a community that deploys WS-Agreement for a particular purpose. I think we've talked around in circles but more or less observe that the underlying semantics of WS-Agreement are consistent with typical legal contracting environments. It may not be complete, but that is because we did not have the charter to try to standardize all aspects of discovery, security, audit, nor domain-specific SLA terminology.
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.
Yes, and yes. We're close to counting angels on pins, I'm afraid...
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?
I think the WS-Agreement decision semantics are clear, but what the terms of the SLA actually mean and how these terms bind the two parties is necessarily domain dependent. Maybe my philosophy is too strange for you, but I have trouble defining obligations and trust in the absence of these domain-dependent concepts. Keeping my spec-authoring hat on, I have to remind myself that I do not know how strongly or weakly the domain-specific terms will capture obligations between parties when someone applies WS-Agreement in practice.
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?
The very concept of "supplier" and "goods" is necessarily domain dependent. Therefore, WS-Agreement cannot make normative statements about this since it does not actually define any normative terms for any actual application domain. That was the general thinking in the working group after this topic was debated before...
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).
Because it was an "unusual" interpretation of what I wrote, i.e. I would say that this step is completely backwards from what I described in my email. Did my reply to Dominic and the graap-wg list not go through? I thought I already pointed out that it was backwards, and repeated the idiomatic advance-reservation solution for 2PC which has the coordinator acting as initiator to both agreements with the resource provider.
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.
To illustrate the underlying WS-Agreement model and roles, it is for a responder to be equipped to receive and consider binding offers, and to shout from the rooftops: here are my templates, please give me offers! And it is for the initiator to somehow (not specified in WS-Agreement) hear these shouted templates, choose among them, formulate an offer, and contact the responder to initiate the protocol. What was marginalized in WS-Agreement was the idea of a customized or multi-round advertisement. It was considered sufficient (for now) to publish advertisements unilaterally, and formulate offers in response to these advertisements. If you want to allow either party to initiate, then the WS-Agreement solution would be for all parties to publish their templates as responders, and for all parties to choose wisely when they would like to become an initiator and make an offer. If you want custom tailored advertisements that take into account your own interests, then you need something more sophisticated. Either an elaborate brokerage/search facility to locate templates or an explicit multi-round discovery protocol. Both of these were set explicitly out of scope for the first version of WS-Agreement.
Sorry, but what does "worst opportunity cost" mean? Please, in a couple of sentences :-)
Michael.
Well, would we agree with this layman's definition of opportunity cost: the lost benefit associated with "locking" a resource and taking it out of play? If so, then the "worst" one is the one that has a higher cost in some global value system! Your judgement about wanting resource providers to be the offeree to avoid live-lock comes from a global view of the system, where you've placed value on the opportunity cost for both parties. E.g., if we stick to the computing environment scenario: the consumer who ties up his "computational units" and the provider who ties up his "computation resources". Then, you've made a judgement that the tying up of resources is a worse outcome than the tying up of the units, presumably because you expect the resources to be scarce or utilization to be the most important metric. This relative evaluation is deeply mired in your assumptions about what the resources are and what it costs the system (society, whatever) to have them tied up. Might there not be a community where the resource providers are hungry for customers and would gladly act as offerors to bid for the right to execute their applications? That possibility is at the heart of our decision to remain silent and allow domain-specific profiles of WS-Agreement to choose how best to apply the protocol. I personally think that this decision should be allowed at runtime, because even within a particular application domain, different participants may have different risk and benefit assessments. In fact, these assessments may vary depending on who they are dealing with. A fully symmetric deployment of WS-Agreement would allow this. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa Corp. and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address.
Hi Karl, On 29 Aug 2007, at 11:44, Karl Czajkowski wrote:
My point was rather that we expect these audit and legal issues to be "mixed in" by a community that deploys WS-Agreement for a particular purpose. I think we've talked around in circles but more or less observe that the underlying semantics of WS-Agreement are consistent with typical legal contracting environments. It may not be complete, but that is because we did not have the charter to try to standardize all aspects of discovery, security, audit, nor domain-specific SLA terminology
My point is that how do you know they can be "mixed in" successfully if they haven't been considered beforehand?
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?
I think the WS-Agreement decision semantics are clear, but what the terms of the SLA actually mean and how these terms bind the two parties is necessarily domain dependent. Maybe my philosophy is too strange for you, but I have trouble defining obligations and trust in the absence of these domain-dependent concepts. Keeping my spec-authoring hat on, I have to remind myself that I do not know how strongly or weakly the domain-specific terms will capture obligations between parties when someone applies WS-Agreement in practice.
With respect, we were talking generally, not specifically about WS- Agreement. I have no doubt the "decision semantics" in WS-Agreement are clear. I was making a general point because you said there were "practical ambiguities" in determining the differences between messages, which we both agree do not exist if the message schema and semantics are agreed to beforehand... About obligations and trust, I agree this is something we cannot solve completely here. But cross-administrative domain contracts in the presence of the threat of enforcement (legally) can help build trust between distrustful parties - therefore it is imperative any agreement/negotiation protocol is consistent with these requirements.
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?
The very concept of "supplier" and "goods" is necessarily domain dependent.
Sorry, I still don't agree. The fact you can use the words "supplier" and "goods" without talking about what you're supplying or which goods you're referring to illustrates they are abstract, domain- independent concepts... I'll also ask my question again: can you give me some real-world examples where the offeror is the supplier/provider of goods? :-)
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).
Because it was an "unusual" interpretation of what I wrote, i.e. I would say that this step is completely backwards from what I described in my email. Did my reply to Dominic and the graap-wg list not go through?
Sorry, but there was no mention in your correspondence to Dominic that the protocol was an "unusual interpretation" of those emails. It doesn't say anything about you feeling step 5 was "completely backwards", though I agree your revised protocol does reverse the offer step. Thanks for clearing this up.
I thought I already pointed out that it was backwards, and repeated the idiomatic advance-reservation solution for 2PC which has the coordinator acting as initiator to both agreements with the resource provider.
Great! If step 5 is "backwards" we're agreed that the resource provider/supplier shouldn't make offers then?
If you want to allow either party to initiate, then the WS-Agreement solution would be for all parties to publish their templates as responders, and for all parties to choose wisely when they would like to become an initiator and make an offer.
Yes, precisely my point from my last email - the offeror needs to take care. A wise provider/supplier should, therefore, always choose to be the offeree - the point we made in our paper.
If you want custom tailored advertisements that take into account your own interests, then you need something more sophisticated. Either an elaborate brokerage/search facility to locate templates or an explicit multi-round discovery protocol. Both of these were set explicitly out of scope for the first version of WS-Agreement.
I agree that the provision of "tailored advertisements", or quotes, are something else to the general adverts you mention above (although there is no difference in law - they are both 'invites to treat'). But, I don't think this provision has to be "elaborate" or "sophisticated". As I said in a previous email, eCommerce websites, such as flight brokering firms, seem to have no problem providing this.
Your judgement about wanting resource providers to be the offeree to avoid live-lock comes from a global view of the system, where you've placed value on the opportunity cost for both parties. E.g., if we stick to the computing environment scenario: the consumer who ties up his "computational units" and the provider who ties up his "computation resources". Then, you've made a judgement that the tying up of resources is a worse outcome than the tying up of the units, presumably because you expect the resources to be scarce or utilization to be the most important metric.
As we said in the eChallenges paper, taking into account the wider picture, ensuring that (in this case) computational resources are not "tied up" is fairer for all customers too; no single customers can block other customers from making a definite offer on a particular resource unless they are committed to using the service by offering to enter into a binding contract for those resources.
This relative evaluation is deeply mired in your assumptions about what the resources are and what it costs the system (society, whatever) to have them tied up.
If you are referring to the eChallenges paper, then we used computational resource provision as an example because of the audience and conference it was intended for. Because we used this example it does not mean our/my general assumptions are "deeply mired" as to what the resources or goods are, as I hinted at in the 'domain-independent' comment above. From the example resources I gave in my last email (time, money, a book, a house... anything that can be traded) and my comments in previous emails I hoped this was clear, but obviously it wasn't...
Might there not be a community where the resource providers are hungry for customers and would gladly act as offerors to bid for the right to execute their applications?
If these resource providers are "hungry for customers" it may mean they are unattractive or unknown to their potential customers. In the real-world a business would, for example, lower their prices, advertise to raise their profile, provide special discounts, etc. to attract customers. However, they still don't make binding offers - and by doing so they get the benefits of protecting themselves from making offers they cannot fulfil (i.e. mistakes), not having to commit goods until a customer has sent them a binding offer, and protection from denial of service possibilities that would leave them with even less income (as they can offer what they are selling for a higher price whilst another customer makes up their mind - again, allowing them to maximise revenue). As I mentioned above, their customers also get the benefits of knowing that other customers can't block them from making an offer on any goods or services too. Can you provide an example of where resource providers/suppiers would "gladly act as offerors"? :-) Thanks, Michael.
On Aug 30, Michael Parkin modulated:
Hi Karl,
My point is that how do you know they can be "mixed in" successfully if they haven't been considered beforehand?
Well, many possible scenarios were considered beforehand, and that is partly why WS-Agreement took such a long, slow stroll from charter to proposed standard... but once considered, they were not written into the specification since our considerations had no normative weight. I fear that I am losing track of this discussion, which I entered with the sole purpose of trying to clarify expected WS-Agreement usage scenarios. What I want to make clear out of all these discussions is that I think it would be unwise for GRAAP-WG to charter any work on a different transactional decision protocol, given both that the two-cycle reserve/claim idiom was central to the definition of the current proposed standard and that the single-cycle offer/accept risks are unavoidable in any distributed system. Similarly, I assert that it would be unwise to define some sort of multi-step obligating negotiation, as this is best modeled through chained agreements to compose/revise incremental obligations. This captures the actual sequence points of any multi-round obligation including who is obligated and what risks there are due to distributed system faults etc. On the other hand, I think it is clear that there is a need for a "WS-Agreement Primer", something that has been on the back burner in GRAAP-WG since the very early specification drafts, as decisions were made to intentionally avoid polluting the spec with too many tangential discussions. There is also a need for one or more new protocols to capture the different goals people have raised such as "tailored advertisements" and "renegotiation".
With respect, we were talking generally, not specifically about WS- Agreement. I have no doubt the "decision semantics" in WS-Agreement are clear. I was making a general point because you said there were "practical ambiguities" in determining the differences between messages, which we both agree do not exist if the message schema and semantics are agreed to beforehand...
No wonder the confusion---I was talking specifically about WS-Agreement and its motivations... I fear that I am already muddying the waters here in a way that is not helpful to the general GRAAP-WG discussions about how to actually use WS-Agreement or how to consider sensible extensions/complements to the current proposed standard. (The topic of the semantics of a message between untrusted participants is more of a philosophical discussion, best had over beers or your own beverage of choice).
About obligations and trust, I agree this is something we cannot solve completely here. But cross-administrative domain contracts in the presence of the threat of enforcement (legally) can help build trust between distrustful parties - therefore it is imperative any agreement/negotiation protocol is consistent with these requirements.
Is there something about WS-Agreement which you think is inconsistent as such? I am not able to see this now through the confusingly threaded discussion... please, if you would, start new threads with specific inconsistencies or problems you see in the protocol? To my knowledge, none of the regular GRAAP-WG participants who contributed to WS-Agreement were legal/contract experts. We steered clear of things like digital signature in the basic specification partly because we got answers from outside experts that it was best left to localization/composition with other standards. However, I felt that the basic business-to-business scenarios were well represented by the commercial participants.
The very concept of "supplier" and "goods" is necessarily domain dependent.
Sorry, I still don't agree. The fact you can use the words "supplier" and "goods" without talking about what you're supplying or which goods you're referring to illustrates they are abstract, domain- independent concepts...
After all the years spent developing the WS-Agreement specification, I personally can no longer use the words "supplier" and "goods" without qualification. :-) I consider agreements rather to be _trades_ and the identification of goods or direction of a provider-consumer relationship to be in the eye of the beholder. In fact, the general case is probably that both parties are both provider and consumer, and your question boils down to "how much?" are they doing of each.
I'll also ask my question again: can you give me some real-world examples where the offeror is the supplier/provider of goods? :-)
No, but I can give examples where the role is not clear. Consider bandwidth trading, whether in ISP peering relationships or in some dynamically negotiated p2p network. The unit of commodity provided by both parties is equivalent, yet someone needs to be the offeror. I think there are plenty of other examples where the trades are not equal but they are still not as glaringly different as "product" for "money". The choice of roles is more contextually dependent here, getting back to the relative opportunity costs of negotiation which I mentioned previously. The WS-Agreement model was written to remain agnostic on this point, not because we want to encourage "unwise" choice of offeror/offeree roles, but because we could not rule on all possible future applications of the protocol. Anything we wrote would end up being non-normative, so again it was deferred as a topic for "the primer".
Sorry, but there was no mention in your correspondence to Dominic that the protocol was an "unusual interpretation" of those emails. It doesn't say anything about you feeling step 5 was "completely backwards", though I agree your revised protocol does reverse the offer step. Thanks for clearing this up.
Ah, sorry, I thought I had made that more clear. However, let me point out that though a computer provider would be the offeree in both the advance reservation and the job submission agreements in my idiomatic reservation example, it is in effect the offeror for the actual resource consumption decision that is synthesized from these two agreements. The client/consumer is getting an offer of resources in the accepted agreement and choosing to accept or reject by either submitting his claiming agreement (to run the job) or canceling the reservation.
But, I don't think this provision has to be "elaborate" or "sophisticated". As I said in a previous email, eCommerce websites, such as flight brokering firms, seem to have no problem providing this.
These interfaces are elaborate, as compared to WS-Agreement in two significant ways: 1. Some of them require human intelligence in one party, whether to construct the request, formulate a query, or filter through "fuzzy" results. This is not acceptable for WS-Agreement which has among its intended audiences machine-to-machine negotiation for resource management. 2. They have domain-specific data models and query models to allow appropriate parameterization of the quote-retrieval step. I don't think there is anyone offering up a generic/domain neutral data model and query model that would be sufficiently complete so as to provide real interop. Even the template mechanism in WS-Agreement is arguably incomplete and requires domain-specialization to support real automated negotiation.
As we said in the eChallenges paper, taking into account the wider picture, ensuring that (in this case) computational resources are not "tied up" is fairer for all customers too; no single customers can block other customers from making a definite offer on a particular resource unless they are committed to using the service by offering to enter into a binding contract for those resources.
This sort of argument, however, has often been used in the past to discourage advance reservation in any form. To turn it around, resource providers MAY choose to reduce utilization if they feel that offering timeliness of service via reservation is a good trade-off to improve the utility (or profitability) of their systems. The trick is having appropriate costs for negotiation, so that the "tied up" resources are still profitable. Looking to real world examples, it typically costs me more to reserve a hotel and be a "no show" on the date of arrival than to reserve and then cancel months before my expected visit. It might not serve society if nobody could book rooms in advance and form sane itineraries... yet this is the state of practice in most of the HPC computing space. :-)
Because we used this example it does not mean our/my general assumptions are "deeply mired" as to what the resources or goods are, as I hinted at in the 'domain-independent' comment above. From the example resources I gave in my last email (time, money, a book, a house... anything that can be traded) and my comments in previous emails I hoped this was clear, but obviously it wasn't...
I am reading between the lines here, but I suspect that you are focusing on "money for goods" trades. Otherwise, I think you would agree that the proper bias for the "offeror risk" is not so clear in a general multiple party (many:many) "goods for goods" trading market. Once the units of trade are less disjoint in terms of being available or fungible, I struggle to see an obvious choice of roles. I think it has to be made on a case by case basis. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software
Hi Karl, On Aug 30 2007, Karl Czajkowski wrote:
I fear that I am losing track of this discussion, which I entered with the sole purpose of trying to clarify expected WS-Agreement usage scenarios.
I thought this discussion was/is regarding your feedback on our paper "Challenges in EU Grid Contracts" (see title of thread) in which we asserted that resource providers should not make binding offers, amongst other things. Therefore, I have tried to relate your comments, where possible, to the points we made in that paper. For your benefit I have limited my comments in this email to a couple of things. Limiting my comments does not imply with I agree with everything in your last email (just as in contract law, silence is not an indication of acceptance) but I feel you want to start wrapping this up.
With respect, we were talking generally, not specifically about WS- Agreement. I have no doubt the "decision semantics" in WS-Agreement are clear. I was making a general point because you said there were "practical ambiguities" in determining the differences between messages, which we both agree do not exist if the message schema and semantics are agreed to beforehand...
No wonder the confusion---I was talking specifically about WS-Agreement and its motivations... I fear that I am already muddying the waters here in a way that is not helpful to the general GRAAP-WG discussions about how to actually use WS-Agreement or how to consider sensible extensions/complements to the current proposed standard. (The topic of the semantics of a message between untrusted participants is more of a philosophical discussion, best had over beers or your own beverage of choice).
Sure, if you're ever in Barcelona give me a shout.
Is there something about WS-Agreement which you think is inconsistent as such? I am not able to see this now through the confusingly threaded discussion... please, if you would, start new threads with specific inconsistencies or problems you see in the protocol?
I don't know (because the WS-Agreement specification is complicated and the protocol mixed in with implementation details), and of course.
I'll also ask my question again: can you give me some real-world examples where the offeror is the supplier/provider of goods? :-)
No, but I can give examples where the role is not clear. Consider bandwidth trading, whether in ISP peering relationships or in some dynamically negotiated p2p network. The unit of commodity provided by both parties is equivalent, yet someone needs to be the offeror. I think there are plenty of other examples where the trades are not equal but they are still not as glaringly different as "product" for "money". The choice of roles is more contextually dependent here, getting back to the relative opportunity costs of negotiation which I mentioned previously.
Yes, the choice of roles is "contextually dependent", but the provider will always be the offeree.
However, let me point out that though a computer provider would be the offeree in both the advance reservation and the job submission agreements in my idiomatic reservation example, it is in effect the offeror for the actual resource consumption decision that is synthesized from these two agreements. The client/consumer is getting an offer of resources in the accepted agreement and choosing to accept or reject by either submitting his claiming agreement (to run the job) or canceling the reservation.
Sorry, but is this protocol written up and in the GRAAP-WG documents? If so, please could you tell me where and I will comment on it in another thread.
But, I don't think this provision has to be "elaborate" or "sophisticated". As I said in a previous email, eCommerce websites, such as flight brokering firms, seem to have no problem providing this.
These interfaces are elaborate, as compared to WS-Agreement in two significant ways:
1. Some of them require human intelligence in one party, whether to construct the request, formulate a query, or filter through "fuzzy" results. This is not acceptable for WS-Agreement which has among its intended audiences machine-to-machine negotiation for resource management.
2. They have domain-specific data models and query models to allow appropriate parameterization of the quote-retrieval step.
I don't think there is anyone offering up a generic/domain neutral data model and query model that would be sufficiently complete so as to provide real interop. Even the template mechanism in WS-Agreement is arguably incomplete and requires domain-specialization to support real automated negotiation.
Apologies. Regarding this point, I was referring to the protocols (i.e. semantics and allowed sequence of messages) they use, not the interfaces, message content or strategy (all of which are orthogonal to the protocol). Sorry if this was not clear to you.
As we said in the eChallenges paper, taking into account the wider picture, ensuring that (in this case) computational resources are not "tied up" is fairer for all customers too; no single customers can block other customers from making a definite offer on a particular resource unless they are committed to using the service by offering to enter into a binding contract for those resources.
This sort of argument, however, has often been used in the past to discourage advance reservation in any form.
I know you're getting tired of this thread - and this is my last question - but can you explain how can this point be used to "discourage advance reservation in any form"?
To turn it around, resource providers MAY choose to reduce utilization if they feel that offering timeliness of service via reservation is a good trade-off to improve the utility (or profitability) of their systems.
If they can be more profitable or "improve the utility of their systems" by doing less, for example, then this is ok with me - the operating model of the provider has little to do with the protocol used to create the agreements, which is the same regardless of the internal strategy of the provider/supplier.
The trick is having appropriate costs for negotiation, so that the "tied up" resources are still profitable. Looking to real world examples, it typically costs me more to reserve a hotel and be a "no show" on the date of arrival than to reserve and then cancel months before my expected visit. It might not serve society if nobody could book rooms in advance and form sane itineraries... yet this is the state of practice in most of the HPC computing space. :-)
Again, costs and profitability are a message content/internal strategy issue, which has little to do with the protocol used to create the agreements. Whether I book a room in the New York Hilton or a 1* pension here, the protocol is the same and the hotel is always the offeree. What they charge me in booking or cancellation fees depends on what each provider (of hotel rooms in this case) inserts into their part of the contract during the agreement process.
Because we used this example it does not mean our/my general assumptions are "deeply mired" as to what the resources or goods are, as I hinted at in the 'domain-independent' comment above. From the example resources I gave in my last email (time, money, a book, a house... anything that can be traded) and my comments in previous emails I hoped this was clear, but obviously it wasn't...
I am reading between the lines here, but I suspect that you are focusing on "money for goods" trades.
Then you have read "between the lines" incorrectly. I am not focussed on "money for goods" trades. As I said in the last email I´m interested in resources that can be traded - this does not mean they are always traded for money.
Otherwise, I think you would agree that the proper bias for the "offeror risk" is not so clear in a general multiple party (many:many) "goods for goods" trading market. Once the units of trade are less disjoint in terms of being available or fungible, I struggle to see an obvious choice of roles. I think it has to be made on a case by case basis.
The provider will always choose to be the offeree because of the reasons I explained in my previous emails. If you want me to go through them again, please say so. :-) Thanks, Michael.
participants (3)
-
Karl Czajkowski -
Michael Parkin -
parkinm＠cs.man.ac.uk