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

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

I appreciate the observations related to cost and believe some discussion
is warranted but some observations:

- Lower is better is mostly what you get in routers. For example, OSPF has
a well defined metric but you can import BGP routes into OSPF (and
vice-versa) with default or different metrics. You can add static routes,
changes preferences, etc.

An ALTO Server is no different. It needs to take inputs from different
sources and come up with a cost metric. If we need to define what cost
means I suggest we take the definition from routing folks (for example,
ref PCE/BGP). Do they have one? For example, if I dump the forwarding
table of a router and it shows that for a certain destination the cost is
"50" through a certain interface,  what can I infer from it given the mash
of different inputs a router can take to calculate that?

- Different ALTO Servers might be a problem if they are in different
domains. ALTO servers within a single domain that need to exchange cost
maps need to use the same algorithms.

- Different ALTO servers in different domains in another issue. This was
an issue we worked on:

https://tools.ietf.org/html/draft-penno-alto-cdn-03#page-17

I believe implementations just use BGP cost.

Thanks,

Reinaldo


On 2/23/13 1:23 PM, "Sebastian Kiesel" <[e-mail]> wrote:

>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
>
>_______________________________________________
>alto mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/alto