Subject: Re: [alto] Issue I: Specify behavior of degenerated map filtering service

From: Richard Alimi <[email-masked]>
Date: Thu, 14 Feb 2013 22:10:22 -0800

Agreed.

On Thu, Jan 31, 2013 at 6:29 AM, Wendy Roome <[email-masked]>wrote:

> I'm in favor of returning the complete map, rather than generating a error.
>
> Why?  Because errors are annoying to implement, and they're annoying to
> test in a bake-off. So whenever practical, I prefer to legislate errors
> out of existence by using reasonable defaults.
>
>         - Wendy Roome
>
>
> >Date: Mon, 28 Jan 2013 23:03:56 +0000
> >From: "Reinaldo Penno (repenno)" <[email-masked]>
> >To: "[email-masked]" <[email-masked]>
> >Subject: [alto] ALTO Protocol Outstanding Issue I: Specify behavior of
> >       degenerated map filtering service
> >Message-ID:
> >       <[email-masked]>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Discussion I:  Specify behaviors of degenerated map filtering service
> >
> >Do we enforce non-empty PID/AddressType? If protocol allows empty there
> >are two possible design choices: default to complete map or reporting an
> >Error
> >
> >Proposal going forward: Return complete Map.
> >
> >
> >Thanks,
> >
> >Reinaldo
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Wendy Roome <[email-masked]>
Date: Fri, 15 Feb 2013 15:23:33 -0500

To return to this issue, I suggest we unify them, so that we have Cost
Types -- period. The "Mode" becomes a property of the Cost Type. So if a
server provides numerical & ordinal routingcosts, it provides *two*
separate Cost Types, say "routingcost" and "routingcost-ord".

I believe the result will simplify both clients and servers, and make it
easier for servers to introduce additional cost types.

My suggestion is to extend the Information Resource Directory with a list
of definitions for each Cost Type the server supports. Each Cost Type
definition would give the name of the Cost Type, the mode, and other
attributes. Currently the Information Resource Directory is a dictionary
with one item, "resources". So I propose adding a second item named
"cost-types," whose value is a list of cost-type definitions, as in

  "cost-types" : [
    {
      "name" : "routingcost",
      "value" : "number",
      "mode" : "numerical",
      "measures" : "delay",
      "description" : "Standard routing cost",
    }, { 
      "name" : "hopcount",
      "value" : "number",
      "mode" : "numerical",
      "measures" : "hops",
      "description" : "Simple hop count",
    }, {
      "name" : "routingcost-ord",
      "value" : "number",
      "mode" : "ordinal",
      "measures" : "delay",
      "description" : "Ordinal routing cost",
    }
  ]

Then pretty much delete every reference to a field named "cost-mode".

To get the ball rolling, I've attached proposed replacements for

	Section 5.1. Cost Attributes
	Section 6.7.2. Encoding	Section 6.7.3. Example

If those don't survive the list server, let me know and I'll put them up
on a web server.

If y'all like this idea, I'd be happy to help with the editing.

	- Wendy Roome

>Date: Mon, 28 Jan 2013 23:08:23 +0000
>Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
>	and cost-type to a single type
>
>Discussion II: Unifying cost-mode and cost-type to a single type
>
>e.g., routingcost-num and routingcost-ord
>
>Having a single type simples the protocol since there is just one
>parameter when indicating cost. But it will impact current
>implementations and might loose flexibility.
>
>Proposal: Leave it as is.
>
>Thanks,
>
>Reinaldo

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 16 Feb 2013 15:00:28 +0000

Hi,

As said some time ago, I do support the idea. It is much better structured and simplifies processing (at both sides, I'd say) And it posseses a taste close to the good-ole MIME types I cannot avoiud to appreciate.

Will go through the detailed text later and provide comments (if any) but let's get the ball rolling!

Be goode,

On 15 Feb 2013, at 21:23 , Wendy Roome wrote:

> <sect-5-1.txt><sect-6-7-2.txt><sect-6-7-3.txt>_______________________________________________
> alto mailing list
> [email-masked]

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Richard Alimi <[email-masked]>
Date: Tue, 19 Feb 2013 14:51:55 -0800

This was supposed to go out last night, but evidently the "Reply All"
button was a bit too elusive....

> easier for servers to introduce additional cost types.

I believe that having them separate is a bit more 'normalized' of a form
and has some important benefits. That is, one just has to define what
'hopcount' means once, and then a server can expose that metric in
different forms.  By creating a single opaque identifier, one now has to
register 'hopcount' for each and every "mode" that comes along.  This also
makes it more difficult for a client to understand that if it wants a
particular cost type (but can handle different forms), it has to know
beforehand the exact set of identifiers under which it can find all of the
forms.

For example, consider the following:
(1) Person A registers cost type 'some-new-type' and describes it with
numerical costs
(2) Person B comes along and wants ordinal costs 'with 'some-new-type'.
Person B then has to go through the registration process to create
'some-new-type-ord'.  [ A side point - do we care about the registry
staying clean? Do we have rules on how to construct appropriate cost type
identifiers so they convey whether they are ordinal or numerical? ]
(3) At some point down the line, the Reincarnated ALTO Working Group
decides to add a new 'mode' of cost, such as an array of costs that
indicates the cost's historical value over the past week.
(4) Person C looks at the registry and figures out that they want
'some-new-type' to be available in this new mode. Person C then has to go
and register 'some-new-type-historical' before it can be used. [ And this
is going to happen for each cost type. ]

In short, I think the registry for cost types is going to get messy and
it's going to make it more difficult for a client to say "I want the
hopcount costs but I don't care whether the server gives me the actual
costs, or is just going to rank them".

All that said, I understand this has been brought up in the past and there
are some things that it simplifies (which have been discussed in an earlier
thread) and if there is good consensus for doing this in the working group,
then we can certainly adopt the changes.

Thanks,
Rich

---

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

I respectfully disagree.

1. Why do we have "ordinal" mode at all?  I was told it was because ISPs
were afraid that providing accurate hopcount & delay information would
reveal too much of the internal structure of their network. "Ordinal" mode
allows an ISP to obfuscate the details, but still provides what most clients
need -- a rank ordering.

Given that, why would a production ALTO server (as opposed to a research
testbed) provide both "numerical" and "ordinal" modes for the same cost
type? I'd think the server would provide numerical if it's not afraid to
give away that much detail. Otherwise it would provide only offer ordinal.

On top of that, if you think about it, if a server maintains numerical cost
values, and a client asks for that cost-type in "ordinal" mode, the server
can just return the numerical values.

So I don't think it will be difficult for a server to maintain both modes
for the same cost type, if only because there's no reason for a server to do
that.

2. Why would a client ever want ordinal cost values? The only reason I can
think of is if the client could rely on "1" being the lowest cost. But that
doesn't work, because ordinal values can be anything -- they do not have to
be 1, 2, 3, 4, Š.

So I don't see clients as needing ordinal mode at all. It's just there to
warn clients that this cost isn't linear.

In fact, I'm tempted to suggest that we replace the idea of a "mode"
attribute with a simple binary attribute called "linear." For a linear cost,
40 is twice as high as 20, and 21 is only slightly higher than 20. For a
non-linear cost, 40 is higher than 21, and 21 is higher than 20, but we
don't know by how much.

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.

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.

- Wendy Roome

From:  Richard Alimi <[email-masked]>
Date:  Tue, February 19, 2013 17:51
Subject:  Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
single type

> easier for servers to introduce additional cost types.

I believe that having them separate is a bit more 'normalized' of a form and
has some important benefits. That is, one just has to define what 'hopcount'
means once, and then a server can expose that metric in different forms.  By
creating a single opaque identifier, one now has to register 'hopcount' for
each and every "mode" that comes along.  This also makes it more difficult
for a client to understand that if it wants a particular cost type (but can
handle different forms), it has to know beforehand the exact set of
identifiers under which it can find all of the forms.

For example, consider the following:
(1) Person A registers cost type 'some-new-type' and describes it with
numerical costs
(2) Person B comes along and wants ordinal costs 'with 'some-new-type'.
Person B then has to go through the registration process to create
'some-new-type-ord'.  [ A side point - do we care about the registry staying
clean? Do we have rules on how to construct appropriate cost type
identifiers so they convey whether they are ordinal or numerical? ]
(3) At some point down the line, the Reincarnated ALTO Working Group decides
to add a new 'mode' of cost, such as an array of costs that indicates the
cost's historical value over the past week.
(4) Person C looks at the registry and figures out that they want
'some-new-type' to be available in this new mode. Person C then has to go
and register 'some-new-type-historical' before it can be used. [ And this is
going to happen for each cost type. ]

In short, I think the registry for cost types is going to get messy and it's
going to make it more difficult for a client to say "I want the hopcount
costs but I don't care whether the server gives me the actual costs, or is
just going to rank them".

Thanks,
Rich

---

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

Hello,

Some comments inline...

From: Wendy Roome <[email-masked]<mailto:[email-masked]>>
Date: Wed, 20 Feb 2013 09:49:17 -0500
To: Richard Alimi <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

I respectfully disagree.

1. Why do we have "ordinal" mode at all?  I was told it was because ISPs were afraid that providing accurate hopcount & delay information would reveal too much of the internal structure of their network. "Ordinal" mode allows an ISP to obfuscate the details, but still provides what most clients need -- a rank ordering.

Given that, why would a production ALTO server (as opposed to a research testbed) provide both "numerical" and "ordinal" modes for the same cost type? I'd think the server would provide numerical if it's not afraid to give away that much detail. Otherwise it would provide only offer ordinal.

On top of that, if you think about it, if a server maintains numerical cost values, and a client asks for that cost-type in "ordinal" mode, the server can just return the numerical values.

So I don't think it will be difficult for a server to maintain both modes for the same cost type, if only because there's no reason for a server to do that.

2. Why would a client ever want ordinal cost values? The only reason I can think of is if the client could rely on "1" being the lowest cost. But that doesn't work, because ordinal values can be anything -- they do not have to be 1, 2, 3, 4, ….

So I don't see clients as needing ordinal mode at all. It's just there to warn clients that this cost isn't linear.

In fact, I'm tempted to suggest that we replace the idea of a "mode" attribute with a simple binary attribute called "linear." For a linear cost, 40 is twice as high as 20, and 21 is only slightly higher than 20. For a non-linear cost, 40 is higher than 21, and 21 is higher than 20, but we don't know by how much.

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.

- Wendy Roome

From: Richard Alimi <[email-masked]<mailto:[email-masked]>>
Date: Tue, February 19, 2013 17:51
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

On Fri, Feb 15, 2013 at 12:23 PM, Wendy Roome <[email-masked]<mailto:[email-masked]>> wrote:

I believe that having them separate is a bit more 'normalized' of a form and has some important benefits. That is, one just has to define what 'hopcount' means once, and then a server can expose that metric in different forms.  By creating a single opaque identifier, one now has to register 'hopcount' for each and every "mode" that comes along.  This also makes it more difficult for a client to understand that if it wants a particular cost type (but can handle different forms), it has to know beforehand the exact set of identifiers under which it can find all of the forms.

For example, consider the following:
(1) Person A registers cost type 'some-new-type' and describes it with numerical costs
(2) Person B comes along and wants ordinal costs 'with 'some-new-type'. Person B then has to go through the registration process to create 'some-new-type-ord'.  [ A side point - do we care about the registry staying clean? Do we have rules on how to construct appropriate cost type identifiers so they convey whether they are ordinal or numerical? ]
(3) At some point down the line, the Reincarnated ALTO Working Group decides to add a new 'mode' of cost, such as an array of costs that indicates the cost's historical value over the past week.
(4) Person C looks at the registry and figures out that they want 'some-new-type' to be available in this new mode. Person C then has to go and register 'some-new-type-historical' before it can be used. [ And this is going to happen for each cost type. ]

In short, I think the registry for cost types is going to get messy and it's going to make it more difficult for a client to say "I want the hopcount costs but I don't care whether the server gives me the actual costs, or is just going to rank them".

All that said, I understand this has been brought up in the past and there are some things that it simplifies (which have been discussed in an earlier thread) and if there is good consensus for doing this in the working group, then we can certainly adopt the changes.

Thanks,
Rich

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

---

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

On Wed, Feb 20, 2013 at 6:49 AM, Wendy Roome <[email-masked]>wrote:

> allows an ISP to obfuscate the details, but still provides what most
> clients need -- a rank ordering.
>

> On top of that, if you think about it, if a server maintains numerical
> cost values, and a client asks for that cost-type in "ordinal" mode, the
> server can just return the numerical values.
>

Yep. The idea was to make it easy for servers.

> for the same cost type, if only because there's no reason for a server to
> do that.
>
> doesn't work, because ordinal values can be anything -- they do *not*have to be 1, 2, 3, 4, ….
>

Clients needed to know the difference between when the servers were
providing ordinal values or numerical values. For example, the P4P approach
does not apply to ordinal values.

> attribute with a simple binary attribute called "linear." For a linear
> cost, 40 is twice as high as 20, and 21 is only slightly higher than 20.
> For a non-linear cost, 40 is higher than 21, and 21 is higher than 20, but
> we don't know by how much.
>

If the intent is to rename it, then I think it's a mistake to collapse it
to a boolean value.  Then, that removes flexibility for extensions. For
example, what if someone wanted to add a mode that wasn't represented by a
single number, but rather a key/value map (such as some statistical
information about a measurement).  Having an identifier instead of a
boolean value gives more flexibility for extensions.

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

I think the other replies here have sufficiently backed up the need for a
registry, and addressed the desire to have your own custom type without the
need to register it.  Right?

At this point, would it be useful to have some guidance from the WG chairs
about what exactly should be considered in this thread?  I get the feeling
like we are straying a long way from the initial question (should we
combine cost mode and cost type to a single identifier), and discussing
large changes that would have been (I think) better brought up during WGLC.
 If the WG believes that we should go back and discuss these, that's fine -
I'd just like some clarity on what exactly the open issues with the draft
are.

Thanks,
Rich

---

From: Wendy Roome <[email-masked]>
Date: Mon, 25 Feb 2013 10:30:04 -0500

I agree the client needs to know the mode for a cost type. To use an old
analogy, an "ordinal" cost type is like the warning "Drawing Not To Scale."

But I think the real question is whether "modes" are orthogonal to "cost
types." We've been assuming they are -- we've been assuming any "cost type"
can be presented in any "mode," and that clients would want to select the
mode independently of the cost type.

I don't think that's true. Consider the two modes we have now -- numerical
and ordinal. For costs based on delay or distance, yes, those are orthogonal
-- we can easy transform numerical costs into ordinal costs. But consider a
hopcount cost. The numerical version is already an ordinal, more or less.
Sure, we can disguise the hopcounts by transforming them, but that just
turns an "ordinal" hopcount cost into a general distance-based cost. Why
bother?

And "ordinal" mode is meaningless for the string-valued cost types that have
been proposed in extensions.

On top of that, if modes really are orthogonal -- if the various modes are
mathematical transforms of an underlying "numerical" cost -- why can't the
client do those transforms?  Take "ordinal" mode. It only takes a few lines
of code to convert an arbitrary set of values into the ordinals 1, 2, 3,
etc. If a client wants to rank-order the costs, a client can easily do that.

So I claim that "mode" is really a property of "cost type" -- they should be
unified, not orthogonal. The client must be aware of the mode, because it's
part of the semantics of the cost type. But a client doesn't need to request
"mode" independently of "cost type." If a client wants a "mode" that is a
simple transform of a cost type, the client should do the transform, and
offload the work from the server to the client. And if we define a mode that
isn't a simple transform, then it's inherently part of the definition of the
cost type.

So what would that mean for the protocol?   In the resource directory entry
for a uri, the server would give the cost-type, but not cost-mode. In a
filtered cost-map request, the client would specify cost-type, but not
cost-mode.  And if you accept my suggestion of a "cost-types" list in the
resource directory, the entry for each type would include some sort of
"mode" attribute.

- Wendy Roome

From:  Richard Alimi <[email-masked]>
Date:  Mon, February 25, 2013 01:12
Subject:  Re: [alto] Discussion II: Unifying cost-mode and cost-type to a
single type
> doesn't work, because ordinal values can be anything -- they do not have to be
> 1, 2, 3, 4, Š.
> 

> 
> In fact, I'm tempted to suggest that we replace the idea of a "mode" attribute
> with a simple binary attribute called "linear." For a linear cost, 40 is twice
> as high as 20, and 21 is only slightly higher than 20. For a non-linear cost,
> 40 is higher than 21, and 21 is higher than 20, but we don't know by how much.

If the intent is to rename it, then I think it's a mistake to collapse it to
a boolean value.  Then, that removes flexibility for extensions. For
example, what if someone wanted to add a mode that wasn't represented by a
single number, but rather a key/value map (such as some statistical
information about a measurement).  Having an identifier instead of a boolean
value gives more flexibility for extensions.