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

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 10:08:31 -0700

Is there any additional feedback on this?  If there are no objections,
I think we can add support for opaque types in this revision of the
document.

Ben's comment about whether 'opaque' is really a good name or not is a
good one (opaque implies uninterpreted, but this might actually be
parsed/interpreted by clients).  Any other suggestions? If we were
really coupled to JSON, then we could adopt the JSON types (string,
array, object) as the names of additional cost modes. To me, that
seems to couple the abstract protocol too much to the encoding we
chose.  How about 'typed'? Any other suggestions?

Thanks,
Rich

On Tue, Jun 14, 2011 at 9:10 PM, Richard Alimi <[email-masked]> wrote:
> Hi Ben,
>
> On Mon, Jun 13, 2011 at 3:08 PM, Ben Niven-Jenkins
> <[email-masked]> wrote:
>> Rich,
>>
>> On 8 Jun 2011, at 10:07, Richard Alimi wrote:
>>> On Tue, Jun 7, 2011 at 1:39 AM, Ben Niven-Jenkins
>>>> 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).
>>>>
>>>
>>> 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 clear to me. Do you have a particular use case in mind?
>>>
>>> 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?
>>
>> 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).
>>
>
> Yes, that is a correct understanding.
>
>>>> 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.
>>
>> 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.
>>
>
> 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
>
>>
>> Ben
>>
>>
>

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 25 Oct 2011 15:34:12 -0400

What is wording we are going to use? MUST/SHOULD/MAY?

- opaque things usually have a habit of creating interoperability problems.
Meaning, they create pockets of interoperability to solve a very specific
problem in the expense of create a larger interoperability issue.

On 10/24/11 10:08 AM, "Richard Alimi" <[email-masked]> wrote:

>>>>> 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?
>>>> 
>>> 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).
>>> 
>> 
>>>>> 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?
>>>>> 
>>>> 
>>> 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.
>>> 
>> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 25 Oct 2011 16:17:15 -0400

I would not use 'opaque' as well, in particular, given the benefit of 
strong typed specification in programming languages--I am stretching to 
see the alto specification as a very small language. Does a 'opaque' 
type really mean that it is a privately defined (not standardized) type?

Richard

On 10/25/11 3:34 PM, Reinaldo Penno wrote:
> On 10/24/11 10:08 AM, "Richard Alimi"<[email-masked]>  wrote:
>
>> On Tue, Jun 14, 2011 at 9:10 PM, Richard Alimi<[email-masked]>  wrote:
>>> Hi Ben,
>>>
>>>> Re-reading your reply&  your original e-mail I see that you're really
>>>> client knows what its syntax&  semantics are) but their probably isn't a

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 25 Oct 2011 17:17:15 -0400

I agree. I believe what we are saying is:

- types might might have more arbitratry constructs (TBD), _but_
- all new types need to have a IANA registration

Thanks,

Reinaldo

---

From: Richard Alimi <[email-masked]>
Date: Tue, 25 Oct 2011 15:34:49 -0700

> - all new types need to have a IANA registration

Yes - this would be the intent.  I think that new IANA registrations
for these would need to clearly document the structure (is it a JSON
object, is it an array, etc) and the semantics applied to it (the
semantics part is already in the instructions for the creation of the
IANA registry, the structure part is not and would need to be added).

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Mon, 31 Oct 2011 09:45:14 -0700

After a bit more rumination here, this probably deserves a slide at
the meeting and discussion in the room about a couple of options if we
want to do this.  In particular, I think there are a couple of ways to
go (please let me know if there are others that should be on the
table):

(1) Add another Cost Mode called "string" -- the actual interpretation
can be whatever is defined in the Cost Type registry for the
corresponding Cost Type (the string might actually be JSON itself).
(2) Add another Cost Mode called "typed" (or something similar) --
then allow some set of JSON Values (e.g., objects, arrays, bools,
strings) as the actual values.

Advantages of (1) [ invert them to get the disadvantages of (2) ]:
- Keeps the spec simpler and more straightforward.
- The data-types we accept remains independent of the ALTO protocol
encoding (FWIW, I think this is the major consideration). In
particular, if someone wanted to encode the ALTO protocol in XML,
bencoding, hieroglyphics, or whatever, they don't also need to worry
about how to map all cost values (both already-defined, and not-yet
defined) into their syntax.

Disadvantages of (1) [ invert them to get the advantages of (2) ]:
- Encoding is less elegant.  Costs might look something like:
    "[ \"element1\", \"element2\" ]"
  or
    "{ \"key\": 2 }"
  or
    "true"
  instead of just putting the raw JSON values in there.
- Implementation is probably less-efficient since it presumably can't
re-use the same JSON parser context that is already being used for the
response itself.
- As a corollary to the second advantage of (1) above, encoding of
cost values in some future format may be less-efficient if we force it
to be a string now.

Thoughts?

Thanks,
Rich