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

["Reinaldo Penno (repenno)" <[e-mail]>]

Hello,

Some comments inline...

From: Wendy Roome <[e-mail]<mailto:[e-mail]>>
Date: Wed, 20 Feb 2013 09:49:17 -0500
To: Richard Alimi <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

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.

[RP] You can always define a new cost type and experiment with it. IANA registered means standardization and interop are required.

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.

[RP] ALTO servers can already do that today.  IANA registration does not preclude any of that, and as you say, within a domain you can define whatever cost mode you want. This is not new, IANA registers a few modes/message types/etc and reserves some for private use.


- Wendy Roome

From: Richard Alimi <[e-mail]<mailto:[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]<mailto:[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

_______________________________________________ alto mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/alto