Subject: [alto] Multiple Cost Types in an ALTO Cost Map

From: Richard Alimi <[email-masked]>
Date: Fri, 27 May 2011 09:21:47 -0700

Hi All,

Now that we have posted the -08 version of the protocol draft, it
would be good to get opinions on a couple of remaining issues. This
thread is about allowing multiple Cost Types to appear in a single
Cost Map.

Background:

Sabine has proposed draft-randriamasy-alto-multi-cost-02, in which one
suggested extension was to support multiple costs in a single Cost
Map.  If an ALTO Client is indeed interested in multiple costs
simultaneously from an ALTO Server, this seems like a very natural
extension, and in a couple of offline discussions, it appears to have
traction.

Main Question: are there any objections to providing support for this?

Proposed changes (along with some questions for discussion):

+ Allow an ALTO Server to indicate that it supports multiple costs.
++ Is it worth allowing an ALTO Server to explicitly indicate how many
costs types may be requested simultaneously? (see next for an
alternative)

+ Add an error code for requesting too many ALTO Cost Types (to catch
requests from ALTO Clients that are beyond the capabilities of the
receiving ALTO Server).  This could perhaps be used instead of an
explicit limit advertised by an ALTO Server; an ALTO Client can just
try what it wishes, and then either split it into multiple queries if
it doesn't work. My preference would be this approach since it keeps
the "capabilities" processing cleaner, but I don't feel strongly.

+ Allow an ALTO Client to indicate multiple Cost Types in a request to
the Map Filtering Service (but still indicate a single Cost Mode).
This should be straightforward.
++ Note that an alternative is to allow an ALTO Client to indicate a
vector of (Cost Type, Cost Mode) tuples. I can't quite get my head
around use cases for this. Should this be supported?
++ draft-randriamasy-alto-multi-cost-02 also mentions the requirement
that this mode should be supported only for "numerical" and not
"ordinal".  Though I would imagine "numerical" to be the common case
for something like this, I'm not sure there is a technical reason for
the limitation.  Any reasons to restrict this to a particular Cost
Mode in the specification?

+ Should we try to make Cost Maps with multiple Cost Types available
via the Map Service as well?  Note that you can still get some of the
caching benefits by issuing a redirect (to an alternate URI requested
via GET) in response to a request to the Map Filtering Service.

+ Allow an ALTO Cost Map to have a vector of costs for each
(source,destination) entry, with one element of the vector per
requested Cost Type. The ordering of the vector can be the same as the
ordering of the vector of Cost Types echoed in the response from the
ALTO Server. This basically allows an entry of the Cost Map be a JSON
array instead of a number as it is today.

Beyond the overall question of whether there are any objections, any
feedback on the proposed changes are welcome!

Thanks,
Rich

---

From: Robert Varga <[email-masked]>
Date: Fri, 27 May 2011 20:04:06 +0200

> Hi All,

Hi,

please see inline comments.

> the "capabilities" processing cleaner, but I don't feel strongly.

I think exposing this information in capabilities is better, because the
client has to check them anyway and it gives the client the ability to
match the server's limits exactly, without incurring guessing and error
round trips. We also need to document what the server should do if a
client attempts to exceed the advertised limit.

> around use cases for this. Should this be supported?

I think we should defer to HTTP request pipelining to support this kind
of beast. A typical implementation would split such a request into two
processing units anyway.

> Mode in the specification?

I cannot think of any. Obviously, the ordinal rankings will need to be
done on a per-cost-type basis.

> via GET) in response to a request to the Map Filtering Service.

I think we should keep the symmetry of Map and Map Filtering services,
so yes, both should support multi costs. Another option would be to
advertise the multi-cost capability explicitly so the client can avoid
the round trip.

> array instead of a number as it is today.

I don't think vectors will work, because two different (S, D) entries
can have different sets of Cost Types defined. Or we would need a
special NaN (not present, etc.) marker.

Bye,
Robert

-- 
Robert Varga
Pantheon Technologies, s.r.o.
Mlynske Nivy 56
831 05 Bratislava

---

From: Richard Alimi <[email-masked]>
Date: Fri, 27 May 2011 11:25:39 -0700

Hi Robert,

Thanks for the feedback. A couple of short responses inline.

> done on a per-cost-type basis.

Yes, ordinal would be per-cost-type.

> special NaN (not present, etc.) marker.

Sure - a 'null' would work too in JSON.  The idea was to make it more
compact than specifying a JSON object for each entry of the cost map
(it seemed wasteful in space and processing overhead).

Thanks,
Rich

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