Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

[Richard Alimi <[e-mail]>]

This was supposed to go out last night, but evidently the "Reply All"
button was a bit too elusive....

On Fri, Feb 15, 2013 at 12:23 PM, Wendy Roome <[e-mail]>wrote:

> To return to this issue, I suggest we unify them, so that we have Cost
> Types -- period. The "Mode" becomes a property of the Cost Type. So if a
> server provides numerical & ordinal routingcosts, it provides *two*
> separate Cost Types, say "routingcost" and "routingcost-ord".
>
> I believe the result will simplify both clients and servers, and make it
> easier for servers to introduce additional cost types.
>

I believe that having them separate is a bit more 'normalized' of a form
and has some important benefits. That is, one just has to define what
'hopcount' means once, and then a server can expose that metric in
different forms.  By creating a single opaque identifier, one now has to
register 'hopcount' for each and every "mode" that comes along.  This also
makes it more difficult for a client to understand that if it wants a
particular cost type (but can handle different forms), it has to know
beforehand the exact set of identifiers under which it can find all of the
forms.

For example, consider the following:
(1) Person A registers cost type 'some-new-type' and describes it with
numerical costs
(2) Person B comes along and wants ordinal costs 'with 'some-new-type'.
Person B then has to go through the registration process to create
'some-new-type-ord'.  [ A side point - do we care about the registry
staying clean? Do we have rules on how to construct appropriate cost type
identifiers so they convey whether they are ordinal or numerical? ]
(3) At some point down the line, the Reincarnated ALTO Working Group
decides to add a new 'mode' of cost, such as an array of costs that
indicates the cost's historical value over the past week.
(4) Person C looks at the registry and figures out that they want
'some-new-type' to be available in this new mode. Person C then has to go
and register 'some-new-type-historical' before it can be used. [ And this
is going to happen for each cost type. ]

In short, I think the registry for cost types is going to get messy and
it's going to make it more difficult for a client to say "I want the
hopcount costs but I don't care whether the server gives me the actual
costs, or is just going to rank them".

All that said, I understand this has been brought up in the past and there
are some things that it simplifies (which have been discussed in an earlier
thread) and if there is good consensus for doing this in the working group,
then we can certainly adopt the changes.

Thanks,
Rich


>
> My suggestion is to extend the Information Resource Directory with a list
> of definitions for each Cost Type the server supports. Each Cost Type
> definition would give the name of the Cost Type, the mode, and other
> attributes. Currently the Information Resource Directory is a dictionary
> with one item, "resources". So I propose adding a second item named
> "cost-types," whose value is a list of cost-type definitions, as in
>
>   "cost-types" : [
>     {
>       "name" : "routingcost",
>       "value" : "number",
>       "mode" : "numerical",
>       "measures" : "delay",
>       "description" : "Standard routing cost",
>     }, {
>       "name" : "hopcount",
>       "value" : "number",
>       "mode" : "numerical",
>       "measures" : "hops",
>       "description" : "Simple hop count",
>     }, {
>       "name" : "routingcost-ord",
>       "value" : "number",
>       "mode" : "ordinal",
>       "measures" : "delay",
>       "description" : "Ordinal routing cost",
>     }
>   ]
>
> Then pretty much delete every reference to a field named "cost-mode".
>
>
>
> To get the ball rolling, I've attached proposed replacements for
>
>         Section 5.1. Cost Attributes
>         Section 6.7.2. Encoding Section 6.7.3. Example
>
> If those don't survive the list server, let me know and I'll put them up
> on a web server.
>
> If y'all like this idea, I'd be happy to help with the editing.
>
>         - Wendy Roome
>
>
> >Date: Mon, 28 Jan 2013 23:08:23 +0000
> >From: "Reinaldo Penno (repenno)" <[e-mail]>
> >Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
> >       and cost-type to a single type
> >
> >Discussion II: Unifying cost-mode and cost-type to a single type
> >
> >e.g., routingcost-num and routingcost-ord
> >
> >Having a single type simples the protocol since there is just one
> >parameter when indicating cost. But it will impact current
> >implementations and might loose flexibility.
> >
> >Proposal: Leave it as is.
> >
> >Thanks,
> >
> >Reinaldo
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>
>