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

[Richard Alimi <[e-mail]>]

On Mon, Feb 25, 2013 at 7:30 AM, Wendy Roome <[e-mail]>wrote:

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

No, hopcount isn't ordinal.  There may be internal hops.


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

A new cost mode could be defined.


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

The server may not wish to expose numerical costs.  Ordinal costs / ranks
were one of the early proposals in the working group, and it took quite a
bit of discussion to find a way to merge into the protocol draft we have
today.  If we are proposing to remove ordinal costs, then I fear that we
would be back to square one in building consensus.  Of course, if no one
cares about ordinal costs anymore and we strongly believe that no one will
come back to us in the next couple of years and ask for them, then we could
get rid of them.  It is my understanding that people still care about
supporting ordinal costs, though.


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

I understand your proposal.  I explained what I believe the downsides of
that proposal are earlier in this thread.

[ I'll reiterate that these are all personal opinions.  If the consensus in
the WG is to merge them, then we'll most certainly make the agreed-upon
changes. ]

Rich


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