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

[Wendy Roome <[e-mail]>]

I respectfully disagree.

1. Why do we have "ordinal" mode at all?  I was told it was because ISPs
were afraid that providing accurate hopcount & delay information would
reveal too much of the internal structure of their network. "Ordinal" mode
allows an ISP to obfuscate the details, but still provides what most clients
need -- a rank ordering.

Given that, why would a production ALTO server (as opposed to a research
testbed) provide both "numerical" and "ordinal" modes for the same cost
type? I'd think the server would provide numerical if it's not afraid to
give away that much detail. Otherwise it would provide only offer ordinal.

On top of that, if you think about it, if a server maintains numerical cost
values, and a client asks for that cost-type in "ordinal" mode, the server
can just return the numerical values.

So I don't think it will be difficult for a server to maintain both modes
for the same cost type, if only because there's no reason for a server to do
that.

2. Why would a client ever want ordinal cost values? The only reason I can
think of is if the client could rely on "1" being the lowest cost. But that
doesn't work, because ordinal values can be anything -- they do not have to
be 1, 2, 3, 4, Š.

So I don't see clients as needing ordinal mode at all. It's just there to
warn clients that this cost isn't linear.

In fact, I'm tempted to suggest that we replace the idea of a "mode"
attribute with a simple binary attribute called "linear." For a linear cost,
40 is twice as high as 20, and 21 is only slightly higher than 20. For a
non-linear cost, 40 is higher than 21, and 21 is higher than 20, but we
don't know by how much.

3. Your last point is about registering cost types. Yes, my proposal would
make it harder to register new cost types with the IANA.

But I'll turn that around. Why do we need a central registry for cost types
at all? Why does the IANA need to control them? Sorry if I'm stepping on
someone's favorite idea here, but to me, a central registry seems totally
unnecessary. Worse than that, it's harmful: it will stifle innovation, by
making it much harder to create and experiment with new cost types.

Yes, that means that two independently implemented ALTO servers can each
define a new cost type named "myExtendedCost", with completely different
semantics. So what? What's the problem with that? Clients will know that
"myExtendedCost" is only meaningful within the context of a specific ALTO
server.

Note that the cost type extension I proposed takes over the descriptive
features of the IANA registry, in that it provides all the information about
this new cost type that a potential client needs to know. It doesn't allow
the IANA to manage and control new cost types. But I think that's a good
thing!

So in short, I suggest dropping the central "cost type registry"
requirements completely (Section 9.2). Instead, the ALTO server provides a
description of its cost types in its resource directory. ALTO servers are
free to invent new cost types, to differentiate themselves and provide
additional value.

- Wendy Roome

From:  Richard Alimi <[e-mail]>
Date:  Tue, February 19, 2013 17:51
Subject:  Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
single type

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