Subject: Re: [alto] Protocol issue: multi-cost information

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 7 Nov 2011 18:51:56 +0100

Hi all,

The new version of the "Multi-Cost ALTO" draft 
(http://tools.ietf.org/id/draft-randriamasy-alto-multi-cost-05.txt ) has 
been posted, and integrates discussion elements on other topics such as 
how to represent specific values (see thread on Authoritative status of 
costs) and the question on opaque cost types.

As for the updates on querying multiple cost types (up to section 5):
- new multi-cost specific services have been added to the IRD: the Multi 
Cost Map service, the Filtered Multi Cost Map service and the Endpoint 
Multi Cost Service.
- for the Multi Cost Map service : queries for multiple cost types are 
arranged in an array of cost types, that comes along with a array of the 
corresponding cost modes. The reason for this is to cover the 
possibility of having cost types that are not numerical.
The order in which these costs values are provided is specified in the 
ALTO response, that MUST return an array of cost-types, arranged the 
same way as the value.
- The Multi-costs values are now objects of type DstMultiCosts 
represented now with JSON type JSONArray .
- There is now a rule saying that: for cost types represented with type 
JSONNumber, the cost mode MUST be numerical.  The previous draft 
versions says "SHOULD".  (I saw that some of these "SHOULD" are 
remaining in the draft by mistake and need to be replaced by "MUST").

Is there any objection to this way to process multiple cost types?
Do we still need to specify a "vector" or "array" Cost Mode?

A number of things related to this draft need to be discussed, in 
particular:

- how do we specify some maximal number of Costs per request in the IRD 
and how? I would rather specify it as a capability of each "multi-cost" 
service in the IRD.
- Vectors or arrays used to represent multiple costs values, are rather 
a cost Mode than a cost Type as for the moment, Cost-types map to 
"routingcost, hopcount, ...", that are rather semantic characteristics.
- Is there an objection to associate 'numerical', 'ordinal', 'string', 
'vector' to Cost-Mode?
- what tag do we use to signify "not available" ? After discussions on 
the list, the draft proposes to use a numerical value for numerical costs.
- how do we tag the different "special values" ?

Are their any other thoughts on this proposal? I'll start another thread 
on the "representation of time-varying cost values with scalar and/or 
value arrays" (see sections 5.3 and §6).

Thanks
Sabine

Richard Alimi a écrit :
> I don't have any objections with leaving this as an extension.
>
> Sabine - are you still intending to fill out the details in
> draft-randriamasy-alto-multi-cost?  Perhaps that could be the first
> ALTO protocol extension :)
>
> I could imagine a couple of ways the extension could go:
> (1) Design a new service such as the multicost map service.  This is
> easy within the current protocol (adding new services to the IRD is
> easy without breaking existing clients).
> (2) Treat queries for multiple cost types the same as a query for a
> cost type that is vector (I think this was basically the way we were
> heading in the design discussion previously on the list).  I think
> this requires a bit of a change to the base protocol, but one that we
> proposed a while back (in particular, opaque cost types).  I'll ping
> that thread to see if there are any objections to adding that in this
> revision and we can discuss on that thread if there are.
>
> Thanks
> Rich
>
> On Sat, Aug 27, 2011 at 12:29 PM, Reinaldo Penno <[email-masked]> wrote:
>   
>> I prefer 1.
>>
>>
>> On 8/26/11 11:01 PM, "Enrico Marocco" <[email-masked]>
>> wrote:
>>
>>     
>>> The current specification allows cost maps to convey only one type of
>>> cost information at a time. It has been pointed out that, in some cases,
>>> applications may benefit from the presence of multiple cost-type values
>>> in a single cost map (see draft-randriamasy-alto-multi-cost for a
>>> detailed description of such use cases) and an extension for allowing
>>> that has been proposed.
>>>
>>> Possible options (please express and possibly motivate your preference):
>>>
>>>   1. allow only one type per cost map in the core protocol
>>>      specification and define the syntax and usage of multi-cost maps
>>>      as an extension;
>>>
>>>   2. extend the core protocol specification to allow multi-cost
>>>      information to be queried and provided in base responses;
>>>
>>>   3. other.
>>>       
>> _______________________________________________
>> alto mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>>     
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>   

-- 

---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France 
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE

E-MAIL : [email-masked]
TEL: +33 (0)1 30 77 27 45 
         (On Net) 2 103 27 45
---------------------------------------------------------