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

[parkinm at cs.man.ac.uk]

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.