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

[Richard Alimi <[e-mail]>]

On Wed, Feb 20, 2013 at 6:49 AM, Wendy Roome <[e-mail]>wrote:

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

Yep. The idea was to make it easy for servers.


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

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.


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

I think the other replies here have sufficiently backed up the need for a
registry, and addressed the desire to have your own custom type without the
need to register it.  Right?

At this point, would it be useful to have some guidance from the WG chairs
about what exactly should be considered in this thread?  I get the feeling
like we are straying a long way from the initial question (should we
combine cost mode and cost type to a single identifier), and discussing
large changes that would have been (I think) better brought up during WGLC.
 If the WG believes that we should go back and discuss these, that's fine -
I'd just like some clarity on what exactly the open issues with the draft
are.

Thanks,
Rich


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