On Fri, Feb 22, 2013 at 9:50 AM, Wendy Roome <[email protected]>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)" <[email protected]> > Date: Thu, February 21, 2013 12:16 > To: Bill Roome <[email protected]>, "[email protected]" < > [email protected]> > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
