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

From: Wendy Roome <[email-masked]>
Date: Thu, 21 Feb 2013 11:32:03 -0500

Reinaldo,

I don't think the current ALTO draft is that permissive. Section 6.6.5 (Cost
Types) seems to require that a server register any cost type that doesn't
start with "exp:":

> Identifiers prefixed with ¹priv:¹ are reserved for Private Use
> [RFC5226]. Identifiers prefixed with ¹exp:¹ are reserved for
> Experimental use. All other identifiers appearing in an HTTP request
> or response with an ¹application/alto-*¹ media type MUST be
> registered in the ALTO Cost Types registry Section 9.2.
> 
Also, although we've registered "routingcost" with IANA, I don't consider
that cost type is "interoperable." To me, "interoperable" means that
"routingcost" values would be comparable between servers, so that a cost of
(say) 40 means the same on all ALTO servers. That's clearly not the case.
Nor should it be!

Perhaps I'm missing the point, but as long as an ALTO server has a standard
way to describe its cost types, I don¹t see any advantage to registering
ALTO cost types with the IANA.

- Wendy

> Date: Thu, 21 Feb 2013 16:00:30 +0000
> From: "Reinaldo Penno (repenno)" <[email-masked]>
> 
> Hello,
> 
> Some comments inline...
> 
> From: Wendy Roome
> <[email-masked]<mailto:[email-masked]>>
> Date: Wed, 20 Feb 2013 09:49:17 -0500
> 
> ....
> 
> 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.
> 
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 21 Feb 2013 17:16:34 +0000

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"

From: Wendy Roome <[email-masked]<mailto:[email-masked]>>
Date: Thu, 21 Feb 2013 11:32:03 -0500
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

Reinaldo,

I don't think the current ALTO draft is that permissive. Section 6.6.5 (Cost Types) seems to require that a server register any cost type that doesn't start with "exp:":

Identifiers prefixed with ’priv:’ are reserved for Private Use
[RFC5226]. Identifiers prefixed with ’exp:’ are reserved for
Experimental use. All other identifiers appearing in an HTTP request
or response with an ’application/alto-*’ media type MUST be
registered in the ALTO Cost Types registry Section 9.2.

Also, although we've registered "routingcost" with IANA, I don't consider that cost type is "interoperable." To me, "interoperable" means that "routingcost" values would be comparable between servers, so that a cost of (say) 40 means the same on all ALTO servers. That's clearly not the case. Nor should it be!

Perhaps I'm missing the point, but as long as an ALTO server has a standard way to describe its cost types, I don’t see any advantage to registering ALTO cost types with the IANA.

- Wendy

Date: Thu, 21 Feb 2013 16:00:30 +0000
From: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>

Hello,

Some comments inline...

From: Wendy Roome <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Wed, 20 Feb 2013 09:49:17 -0500

....

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.

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

---

From: Wendy Roome <[email-masked]>
Date: Fri, 22 Feb 2013 12:50:59 -0500

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)" <[email-masked]>
Date:  Thu, February 21, 2013 12:16
To:  Bill Roome <[email-masked]>, "[email-masked]"
<[email-masked]>
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"

---

From: Sebastian Kiesel <[email-masked]>
Date: Sat, 23 Feb 2013 17:23:58 +0100

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

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 23 Feb 2013 21:43:23 +0100

> 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.:
> 

For what it is worth (slightly off-topic in this thread): Approximate geographic location is already explicitly mentioned in the ALTO charter ("Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations.").

IMHO, regarding geographical locations, draft-scharf-alto-vpn-service-00 just suggests something that the charter already mentions.

Michael

---

From: Richard Alimi <[email-masked]>
Date: Sun, 24 Feb 2013 22:18:05 -0800

On Fri, Feb 22, 2013 at 9:50 AM, Wendy Roome <[email-masked]>wrote:

> 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.
>
> 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

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

> To: Bill Roome <[email-masked]>, "[email-masked]" <
> [email-masked]>
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 25 Feb 2013 16:51:12 +0000

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" <[email-masked]> wrote:

>>Types.
>>manager
>>help.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 25 Feb 2013 19:07:23 +0100

> 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.

Yes. One can indeed use different input sources...

> 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?

... and there may be input metrics other than BGP/OSPF/... routing cost.

> - 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:
> 

While BGP cost is certainly a very relevant input parameter, we've shown an implementation that can also calculate the ALTO cost e.g. from delay (Section IV.C): http://dx.doi.org/10.1109/ICIN.2012.6376038

How to calculate the cost value really depends on the requirements and policies of the ALTO server operator.

Michael