Subject: Re: [alto] Opaque Cost Types in ALTO Cost Maps

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 7 Jun 2011 09:39:54 +0100

Rich,

On 27 May 2011, at 17:33, Richard Alimi wrote:

> Hi All,
> 
> This email describes a possible extension to ALTO Cost Maps that has
> been discussed with a couple of people. We are looking for additional
> feedback here.

I am not entirely sure what you are asking for feedback on, your mail talks about enumerated values but I suspect the question you are asking is wider than just enumerated values (as you also mention strings, arrays, etc. later).

Enumerated values are probably a straightforward extension as one could still maintain that costs are encoded as numbers. The use case for carrying arbitrary bitstrings, JSON objects etc. is less clear to me. Do you have a particular use case in mind?

Also I am assuming that any cost-types constructed of enumerated values, bitstrings, etc. would belong to new sets of cost-modes to the numerical/ordinal modes currently defined?

Thanks
Ben

> 
> It has been suggested that ALTO Cost Maps can convey additional
> information beyond just raw "costs" (e.g., some numerical measurement
> associated with a source, destination pair).  For example, one might
> wish to allow an ALTO Cost Map to indicate that a source,destination
> pair in an ALTO Cost Map has a particular enumerated value associated
> with it (e.g., whether it is completely within an AS or not, crosses a
> peering link, etc).
> 
> In this sense, it is more of a Path Property (an earlier version of
> the protocol draft used this terminology, but "cost" seemed more
> natural to readers at that time).  I'd proposed not to worry about the
> terminology at this point; we can address on a separate thread when/if
> making revisions to the draft to support this.
> 
> To be clear, the data type and semantics of the Cost Type will still
> be indicated in the registration. This means that the registration
> should indicate whether its a boolean, string, enumerated value (e.g.,
> valid values and the meaning of each of the values), an array, or even
> a JSON object itself.
> 
> Note that this is *not* a proposal to change the format of the
> 'routingcost' type. That is still a number and would remain as such.
> This is a proposal to add another degree of freedom when registering
> additional Cost Types.
> 
> Thoughts about this proposal? Objections?
> 
> Thanks,
> Rich
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Wed, 8 Jun 2011 02:07:18 -0700

Hi Ben,

> I am not entirely sure what you are asking for feedback on, your mail talks about enumerated values but I suspect the question you are asking is wider than just enumerated values (as you also menti…

The general question was whether we should support cost types other
than numbers.  However, you've brought up a good question of whether
we should narrow that down to strings, or keep it open to any JSON
value (e.g., bool, object).

> Enumerated values are probably a straightforward extension as one could still maintain that costs are encoded as numbers. The use case for carrying arbitrary bitstrings, JSON objects etc. is less c…

While enumerated values is what I mentioned below, I'm not sure I see
a reason to restrict the protocol to that. For example, an ALTO Server
might want to indicate that a particular source/dest pair fits a
particular criterion or not (e.g., does it cross a peering link or
not); it seems like it would be more natural in the protocol,
registration of the cost-type, and implementation to make that a
boolean value than force it into a numerical value.

Is there a compelling reason to be more restrictive here?

> Also I am assuming that any cost-types constructed of enumerated values, bitstrings, etc. would belong to new sets of cost-modes to the numerical/ordinal modes currently defined?

Good question. There are a couple of approaches I can think of here:
(1) Rename 'numerical' to 'value' (or something similar), and it can
either be a number or some other JSON value.  'ordinal' would stay as
it is, and it implies that the cost -type defines some ordering
semantics (this would be defined in the cost-type registry).
(2) Add a new cost mode of 'opaque'.

Thinking about it quickly, (1) seems cleaner to me.

Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:08:57 +0100

Rich,

> Is there a compelling reason to be more restrictive here?

When I first replied I was thinking ion terms of the value of the enumeration/bitstrings/etc being a true cost and I was struggling to see how one could do comparison/summation between arbitrary bitstrings/JSON objects etc.

Re-reading your reply & your original e-mail I see that you're really talking about "path properties" in which case the definition of the contents of the bitstring/JSON object/etc. would typically need to be specified (so a client knows what its syntax & semantics are) but their probably isn't a need for a client to be able to directly compare two arbitrary bitstrings/etc. and figure out which one is "higher" (of course it could use policy to say prefer property X over property Y but that's a different type of comparison).

> Thinking about it quickly, (1) seems cleaner to me.

I'd disagree. The "numerical" mode allows numerical operations to be performed on returned costs (e.g. summation) which only really applies to numbers.

I'm not sure whether I like the idea of (2) or not. I think it might depend on the scope of the information. If it is truly opaque and is not meant to be understood by the client (but might be used in some way - e.g. a "friendly name" for display purposes/debugging etc) opaque value is appropriate. If it's meant to be a place to stuff data an ALTO client is meant to understand then I'd prefer to have explicitly specified and typed cost-modes for that sort of data.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Tue, 14 Jun 2011 21:10:31 -0700

Hi Ben,

> Re-reading your reply & your original e-mail I see that you're really talking about "path properties" in which case the definition of the contents of the bitstring/JSON object/etc. would typically…

Yes, that is a correct understanding.

> I'm not sure whether I like the idea of (2) or not. I think it might depend on the scope of the information. If it is truly opaque and is not meant to be understood by the client (but might be used…

That's one way to think about it.  Though, another way to think about
it is to define the set of operations as part of the cost type.  That
said, 'numerical' seems common enough to have its own mode, and likely
one of the defaults.  'opaque' would be there as the more general
extension mechanism.  I'm fine with this.

Thanks,
Rich