Re: [alto] Discussion on how to encode element values of a cost map

[Gao Kai <[e-mail]>]

Jensen, Richard and all,

I'd like to propose some other issues beside Jensen's:

1) How to represent the current data schema
2) How to declare the data schema precisely in the capabilities

Most JSON libraries would have no problem "parsing" the result, since a
JSONValue can always be converted to an array, an object or a primitive
type (scalar value).  The question is how the application/client and the
server have the same understanding of the data.  For example, some
extensions have already taken into consideration the compatibility with
multi-cost, but if such extensions are to be combined together, what is
the correct processing order?

One solution, as Jensen proposes, is to usea data schema.  The client
can pre-compile its schema tree used in a request so that the ALTO
library can correctly understand the structure of the cost value. 
However, instead of using the cost-schema, Ithink maybe it is possible
to extend the cost types directly, and all the options can be embedded
in the query.  For example,

{
    "cost-metric": "multicost",
    "cost-mode": "compound",  // or "vector", makes no difference now
    "multi-cost-types": [
        {"cost-metric": "calendar", "cost-mode": "compound",
"calendar-type": [
            {"cost-metric": "routingcost", "cost-mode": "numerical"}
        ], "calendar-attributes": {...}}
    ]
}

However, it can still be very painful for the server to declare the
capabilities precisely.  Haven't got a good solution for that now.

Regards,
Kai


On 19/07/16 03:08, Jensen Zhang wrote:
> Personally speaking, I think there are two issues about cost-type
> definition:
>
> 1) How to make the compound type compatible with RFC7285;
> 2) How to extend single cost-type easily. (Maybe we want to support
> generic types)
>
> A simple design I think is to introduce a special cost-mode called
> "compound". When cost-mode value is "compound", "multi-cost-types"
> field will be required. If the cost-mode value is not equal to
> "compound", we need to suppose the cost-type is always a single type.
>
> I don't think about the benefit from supporting generic types very
> clearly. We can introduce another some basic cost-mode like identity,
> vector and map.
>
> The recommended usage can look like:
>
> if meta.cost-type.cost-mode == "compound"
>   ElemType is array && "multi-cost-types" field is required
> else if meta.cost-type.cost-mode == "numerical"
>   ElemType is number
> else if meta.cost-type.mode == "ordinal"
>   ElemType is non-negative int
> else if meta.cost-type.mode == "identity"
>   ElemType is string
> else if meta.cost-type.mode == "vector"
>   ElemType is array
> else if meta.cost-type.mode == "map"
>   ElemType is object
>
> I think it is general enough to express arbitrary JSONValue. But I am
> not sure making the cost-mode cover generic types is helpful.
> Actually, "vector" and "map" are not single types. They are compound
> types indeed. If we want to express the cost-type accurately, one
> solution I think is to introduce a new field called "cost-schema" in
> cost-type:
>
> object {
>          CostMetric cost-metric;
>          CostMode   cost-mode;
>          [CostSchema cost-schema;]
>          [JSONString description;]
>        } CostType;
>
> The cost-schema field for cost-type is just like DTD for xml. And we
> can design complex compound types by using cost-schema.
>
> But I don't plan to deprecate "multi-cost-types" field. Because I
> think multi-cost is not a compound type but a class of compound types.
> For example, cost-maps with multi-cost [bw, hopcount] and with
> [hopcount, delay] can have the same capability [bw, hopcount, delay].
>
> The above is my current thought.
>
> Best,
> Jensen
>
> On Mon, Jul 18, 2016 at 8:11 AM, Y. Richard Yang <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi all,
>
>     Several of us are reviewing the documents in the WG. Here is one
>     common issue: We see that quite a few documents depend on encoding
>     the types of the elements in a cost map. This is a complexity that
>     the based protocol RFC7285 identifies and hence decided to make
>     the type the generic type JSONValue. But in the spirit of being
>     strong typed, a specific cost map needs an indication of the type.
>     For those who need some review, please see:
>
>     - Cost Map
>     response: https://tools.ietf.org/html/rfc7285#section-11.2.3.6
>       Requirements: 
>
>         media-type: application/alto-costmap+json
>
>         meta: MUST include cost-type and dependent-tag of the network map
>
>         data: "An implementation of the protocol in this document
>         SHOULD assume that the cost is a JSONNumber and fail to parse
>     if it
>         is not, unless the implementation is using an extension to this
>         document that indicates when and how costs of other data types are
>         signaled."
>
>     - Filtered Cost Map
>     response: https://tools.ietf.org/html/rfc7285#section-11.3.2
>
>       Defined as the same as Cost Map.
>
>     - Endpoint Cost
>     Service: https://tools.ietf.org/html/rfc7285#section-11.5.1
>
>         media-type: application/alto-endpointcost+json
>         meta: "The "meta" field of an endpoint cost response MUST
>     include the "cost-
>        type" field, to indicate the cost type used."
>
>     The current definition of cost-type has two components: cost-mode
>     and cost-metric,
>     and cost-mode has two values defined: numerical and ordinal, both
>     indicate a single
>     number. At the same time, multiple active drafts
>     (https://datatracker.ietf.org/wg/alto/documents/)
>     need compound types for the elements of a cost map:
>
>     - [multi-cost] 
>     This draft is probably the one which we need to resolve the issue
>     the most urgent. Assume that
>     it uses the current alto-costmap+json media type, then it cannot
>     satisfy the requirement of "meta"
>     including cost-type.
>
>     - [cost-calendar]
>     Cost calendar requires a compound data type as well.
>
>     - [fcs]
>     fcs depends on multi-cost and hence can have an issue as well.
>
>     - [path-vector]
>     The current definition of path-vector needs a vector of network
>     elements. 
>
>     - [te-metrics]
>     It appears that this document is fine, but may need to watch on
>     related consistency issues.
>
>     The preceding is not a minor syntax/encoding issue. How to handle
>     types is a basic problem. 
>     Conceptually, a cost map, as in the base protocol is param'ed type:
>     Map< String, Map< String, ElemType > >
>
>     (Note: Some may argue that String above should be typed identifier.)
>
>     So far, we have defined ElemType to be JSONValue, and used the
>     cost-type to indicate more specifics:
>     if meta.cost-type.cost-mode == "numerical"
>       ElemType is float
>     else if meta.cost-type.mode == "ordinal"
>       ElemType is non-negative int
>
>     My personal feeling is that we may need to start to introduce new
>     cost-mode values to allow generic types. For those who are PL
>     experts, it is a good chance to chime in. It is an important issue
>     that the WG may want to work together to achieve a consistent,
>     extensible design.
>
>     Cheers,
>     Richard
>
>     References:
>     -
>     [multi-cost] https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/
>     - [cost-calendar]
>     https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/
>     - [fcs] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/
>     -
>     [path-vector] https://datatracker.ietf.org/doc/draft-yang-alto-path-vector/
>     -
>     [te-metrics] https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics/
>
>     _______________________________________________
>     alto mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/alto
>
>