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

On Fri, Feb 22, 2013 at 9:50 AM, Wendy Roome <w.roome@alcatel-lucent.com>wrote:

> Okay, I can avoid the IANA registration requirements by using "priv:" or
> "exp:" for custom Cost Types.
>
> But that doesn't answer the question of *why* we should register Cost
> Types. What's the advantage? How does that benefit us? That's a serious
> question. To me, registration looks like an annoyance without any redeeming
> benefit.
>
> I realize that the goal might have been to make costs interoperable, but I
> don't think registration accomplishes that. Take "routingcost". I believe
> all the IANA registration says is that "routingcost is a non-negative
> number, and lower is better". I don't think that's enough. To make
> routingcost interoperable, I'd like to know what "40" means. Better yet, I
> think "interoperable" would mean that I could compare routingcost values
> between different ALTO servers, so 40 on one server means roughly the same
> as 40 on another server.
>
> That's clearly not true.
>
> Here's a sample use-case. I want to select a host for new VM. The VM
> manager gives me the CPU load (0.0 to 1.0) for several hosts. I then ask an
> ALTO server for the routingcosts between my client and each of those hosts.
> I run a function to blend the alto cost and the cpu load into an overall
> cost, using the appropriate weighting and scaling factors, and I select the
> host with the lowest overall cost.
>
> So how do I determine those scaling factors? The IANA registry doesn't
> help. I have to talk to the folks who provide that ALTO server, or else
> just look at the values it returns. If I switch to a different ALTO server,
> I'll have to start over again.
>
> To me, that is not "interoperable". To me, "interoperable" would mean that
> I could determine the scaling factors just from the central registry, and
> use the same factors with any ALTO server.
>
> As it stands now, "routingcost" values are only meaningful in the context
> of a specific ALTO server. So even though "routingcost" is registered, it's
> still a custom cost that varies widely from server to server. So what's the
> benefit to registration?
>

Some context here: routingcost was intended to be a generic numerical value
that was roughly correlated with the 'goodness' of the source/destination
pair, but we intentionally stayed away from a rigorous definition.  The
belief was that this gives service providers a way to expose a cost that
has benefits to clients without explicitly communicating the basis for that
cost. The P4P approach and its field trials were a good example that even
this can have solid benefits in the real world; we asked multiple service
providers to devise costs but did not give any guidance on how to choose
them.

All that said, I think the other replies here have shown the desire and use
cases for additional cost types that have more formal definitions.

Thanks,
Rich

>
> Sorry to be a pest, but it seems that a while back, someone just declared,
> "Well, of course we should to register cost types!" Since then we've all
> accepted that on blind faith. All I'm asking is for is why registration
> helps.
>
> - Wendy Roome
>
>
> From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
> Date: Thu, February 21, 2013 12:16
> To: Bill Roome <w.roome@alcatel-lucent.com>, "alto@ietf.org" <
> alto@ietf.org>
>
> Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
> single type
>
> This is what you need. A private cost you can use within your ALTO servers
> and domain.
>
> "Identifiers prefixed with ’priv:’ are reserved for Private Use"
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>