Subject: Re: [alto] Unifying cost-mode and cost-type

From: Wendy Roome <[email-masked]>
Date: Wed, 30 Jan 2013 14:12:18 -0500

I realize it's late to make changes, but I really think unifying type &
mode makes a lot of sense.  Here's my suggestion: extend the "resource
directory" to include a generalized description of the cost-types that the
server provides.  I won't suggest a syntax -- too early for that!! -- but
here's what the description should provide for each distinct type:

* The type name.  This is what clients give in the cost-type parameter.

* The value type.  "numerical" & "string" are obvious possibilities.

* Linear: a boolean flag. True means this numeric value is linear.
  False means values are not linear. This takes the place of
  the ordinal/numerical mode.

* Category: What this cost measures: "delay", "hops", "cost", "other".
  Here "cost" means money.

* Description: An optional free-form description of this cost type.
  For human consumption, to be used when investigating a new ALTO server.

* URL: An optional url with a detailed description of this cost type.
  For more involved "Descriptions", of course. This can be in
  multiple languages, of course.

Yes, the change would be painful, but I think it will simplify the
protocol, servers and clients -- AND it will make it easier for servers to
add new cost types.

To simplify clients, we might reserve a few type names, such as
   routingcost-numerical
   routingcost-ordinal
   hopcount-numerical
   hopcount-ordinal
and require them to have the obvious descriptions.

	- Wendy Roome

On 01/29/2013 15:00, "[email-masked]" <[email-masked]> wrote:

>Date: Mon, 28 Jan 2013 23:08:23 +0000
>From: "Reinaldo Penno (repenno)" <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
>	and cost-type to a single type
>Message-ID:
>	<[email-masked]>
>Content-Type: text/plain; charset="us-ascii"
>
>Hello,
>
>Please send your comments to the list in the next 2 weeks. Silence means
>we will go with the proposal.
>
>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: Wendy Roome <[email-masked]>
Date: Thu, 31 Jan 2013 09:29:36 -0500

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
>Subject: [alto] ALTO Protocol Outstanding Issue I: Specify behavior of
>	degenerated map filtering service
>Message-ID:
>	<[email-masked]>
>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