[ogsa-rss-wg] Candidate Ordering Language

[Ramin Yahyapour]

Soonwook Hwang wrote the following on 21.12.2005 11:23:
>  
>>       In order to deal with values that are expressed as xsd:dateTime
>>       instead of numerics, value has an optional base attribute and the
>>       result is the difference between the base time and the "value" time
>>       in *seconds*.
>>
> It's not clear to me about the idea behind the result returned
> with difference between the base time and the "value" time in case
> that the values are expressed as xsd:dataTime. Do you have some
> usage cases about this?

I assume Donal just want to be able to calculate with time
as well as with other scalar values in this ordering language.
That means, you might want to write
"order by (x*starttime + y*CPU#)"
In that case it is essential how starttime is mapped to a scalar
value.

> 
>> Example:
>>
>> The value is the sum of the price times a constant factor, and the
>> inverse square root of the number of CPUs allocated (using some schema
>> for offers that I've picked out of the air)...
>>
>>     <sum>
>>       <product>
>>         <value> //price/@value </value>
>>         <constant> 42 </constant>
>>       </product>
>>       <power exponent="-0.5">
>>         <!-- Assume that somewhere there's some JSDL -->
>>         <value> //JobDescription/Resources/IndividualCPUCount </value>
>>       </power>
>>     </sum>
>>
>> Or something like that. And this very simple structure has the advantage
>> of being both pretty easy to implement (once you have XPath) and free of
>> programming language nasties.
>>
>> Is this sufficient? Or too complicated? Have I missed anything obvious?
>>
>> (The other major alternative is to define a language that can compare
>> two terms, but that's likely to be more difficult to do, and it can
>> easily lead to ill-defined orderings, i.e. where there is no partial
>> order on the offers at all. A scoring function doesn't have those
> problems.) 
> 
> In general, I think I am fine with the language that you have 
> come up with. However, I am wondering what it means to have 
> as a returned ranking value the summation of the price (where dollar 
> or completion time is likely used as its unit value) and the 
> CPUCount (with the unit of CPU #). What dose it mean to sum
> Momory size and CPU speed? 

I assume Donal is trying to model an individual objective function
for a candidate request. In this request someone may specify some
complex function which can be evaluated to get a scalar value for
each candidate. This value can be used for ordering.

In such a scenario, it is quite common to restrict the model to simple
functions in which you add weights to the potential variable parameters
(as done here with memory and CPU#). Due to the given weight factors
you specify your personal preferences for certain candidate configuration.
Thus, you could set the weights accordingly and have such a function as Donal
mentioned in which you sum up CPUcount and price with these weights.

Otherwise, the language is fine for me.
At our site we did a similar approach in the past. However, we built a richer
language in which we allowed conditional statements (if/then).
Assuming that part of your ordering formulation might depend on the
availability of certain resource features you might shift your weights
and the complete function. Let's say, if memory is below 4GB you would
put more weight on this feature, if it is above, you might focus on other
values like price or responsetime.

But anyway, we should not make this language too complicated at this point.
Thus I would suggest to restrict on basic features. Adding more complexity
later should not be a problem here.


Ramin

-- 
Dr.-Ing. Ramin Yahyapour         | mailto:Ramin.Yahyapour at uni-dortmund.de
Computer Engineering Institute   | phone: +49 (231) 755-2735
University of Dortmund           | mobil: +49 (179) 5261973
44221 Dortmund / Germany         | fax:   +49 (231) 755-3251