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

[Sebastian Kiesel <[e-mail]>]

Hi,

your observations regarding the "routing cost" cost type are right - we
cannot say more than "lower ist better" and there is no way to compare
values retrieved from different ALTO servers. This was a conscious
decision for the default cost type.  Personally, I would have preferred
to call the default cost type "relative preference" in order to 1) show
that this is indeed a relative measure, 2) remove the ambiguity whether
cost is to be understood in the sense of routing protocols as opposed to
monetary cost for sending traffic over specific links, and 3) explicitly
allow the ALTO server operator to express preferences based on
completely different issues than "cost".


On the other hand, there are many other cost types (or "rating
criteria", as the ALTO requirements document RFC 6708 calls them), where
an exact specification how to compute and how to encode them makes
sense, e.g.:

- draft-scharf-alto-vpn-service-00  talks about publishing the
  geographical location of a data center using ALTO. How excatly
  do we encode longitude/latitude?   This might fit into two lines
  of text directly in the IANA registry.

- Hop count, defined as the one-way TTL decrease you will observe 
  in the IP packet header when sending packets to the target host
  -> a well defined measure that can be compared among servers

- Weighted path length, maybe something like 

path_length := 
    2 * (Number of traversed  10 Gbps links in the access networks)
  + 4 * (Number of traversed   1 Gbps links in the access networks)
 + 19 * (Number of traversed 100 Mbps links in the access networks)
 + 100 *(Number of traversed  10 Mbps links in the access networks)
 + 30 * (Number of traversed Autonomous Systems between the access n.w's)

  This is for illustration only - the weights in each line probably need
  tweaking.  Such a rather long definition probably needs an own
  specification document before registering.
  
- For a longer list of other criteria we discussed long time ago see 
  section 5 of http://tools.ietf.org/id/draft-ietf-alto-reqs-06.txt



So for me the conclusion is: the fact that we cannot compare our
default cost type "routing cost" between different ALTO servers does
not contradict the need to establish a registry for registering and
defining more complex cost types, which may or may not have clear
scaling factors or units of measurement.

Thanks
Sebastian






On Fri, Feb 22, 2013 at 12:50:59PM -0500, Wendy Roome 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?
> 
> 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)" <[e-mail]>
> Date:  Thu, February 21, 2013 12:16
> To:  Bill Roome <[e-mail]>, "[e-mail]"
> <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto