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 protected]> wrote:
I prefer 1.
On 8/26/11 11:01 PM, "Enrico Marocco" <[email protected]>
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 protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
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 protected]
TEL: +33 (0)1 30 77 27 45
(On Net) 2 103 27 45
---------------------------------------------------------
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
