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

[Wendy Roome <[e-mail]>]

I agree the client needs to know the mode for a cost type. To use an old
analogy, an "ordinal" cost type is like the warning "Drawing Not To Scale."

But I think the real question is whether "modes" are orthogonal to "cost
types." We've been assuming they are -- we've been assuming any "cost type"
can be presented in any "mode," and that clients would want to select the
mode independently of the cost type.

I don't think that's true. Consider the two modes we have now -- numerical
and ordinal. For costs based on delay or distance, yes, those are orthogonal
-- we can easy transform numerical costs into ordinal costs. But consider a
hopcount cost. The numerical version is already an ordinal, more or less.
Sure, we can disguise the hopcounts by transforming them, but that just
turns an "ordinal" hopcount cost into a general distance-based cost. Why
bother?

And "ordinal" mode is meaningless for the string-valued cost types that have
been proposed in extensions.

On top of that, if modes really are orthogonal -- if the various modes are
mathematical transforms of an underlying "numerical" cost -- why can't the
client do those transforms?  Take "ordinal" mode. It only takes a few lines
of code to convert an arbitrary set of values into the ordinals 1, 2, 3,
etc. If a client wants to rank-order the costs, a client can easily do that.

So I claim that "mode" is really a property of "cost type" -- they should be
unified, not orthogonal. The client must be aware of the mode, because it's
part of the semantics of the cost type. But a client doesn't need to request
"mode" independently of "cost type." If a client wants a "mode" that is a
simple transform of a cost type, the client should do the transform, and
offload the work from the server to the client. And if we define a mode that
isn't a simple transform, then it's inherently part of the definition of the
cost type.

So what would that mean for the protocol?   In the resource directory entry
for a uri, the server would give the cost-type, but not cost-mode. In a
filtered cost-map request, the client would specify cost-type, but not
cost-mode.  And if you accept my suggestion of a "cost-types" list in the
resource directory, the entry for each type would include some sort of
"mode" attribute.

- Wendy Roome


From:  Richard Alimi <[e-mail]>
Date:  Mon, February 25, 2013 01:12
Subject:  Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
single type
> 
> 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.

Clients needed to know the difference between when the servers were
providing ordinal values or numerical values. For example, the P4P approach
does not apply to ordinal values.

> 
> 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.

If the intent is to rename it, then I think it's a mistake to collapse it to
a boolean value.  Then, that removes flexibility for extensions. For
example, what if someone wanted to add a mode that wasn't represented by a
single number, but rather a key/value map (such as some statistical
information about a measurement).  Having an identifier instead of a boolean
value gives more flexibility for extensions.