Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map

From: Wendy Roome <[email-masked]>
Date: Mon, 15 Jul 2013 12:15:06 -0400

At the risk of being a nudge, I'm going to suggest what I think is the
only practical way to handle multiple network maps in one IRD.

Namely, treat multiple network maps the same way we treat multiple cost
metrics: name them, register the names, and define basic semantics for
each network map name.

That means each network-map service would have capabilities with the name
of the network map it returns. A filtered map service's entry would have a
list of names, and a filter map request would allow the client to specify
the network map name.  Cost map services would have to indicate the
network map name as well as the cost-type name. Or we could make the
network-map name part of the cost-type name.

I'll even suggest a set of network map names to register

provider -- Has detailed PIDs for the provider's coverage area. As you get
away from that area, PIDs become much coarser-grained.

local -- Has detailed PIDs near 'the client' (whoever the perceived client
is). As you get away from that area, PIDs become much coarser-grained.
This would be appropriate for an IRD returned by discovery, where the
client is the entity requesting the IRD.

coarse -- A coarse-grained map that covers the entire planet with the same
(low) level of detail. Implies that there are 10's of PIDs, they are
sub-continent level, and they rarely change.

detailed -- A fine-grained map that covers the entire planet at the same
(high) level of detail. Potentially has 1000's of PIDs. PIDs and costs
might change frequently.

Comments????

	- Wendy ("Doesn't know when to keep her mouth shut") Roome

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Jul 2013 20:12:11 +0100

Wendy, Colleagues,

I simply do not think we need this level of complexity, registration or constraints. I see the world quite simply.

We can have multiple network maps in an IRD so we agreed to allow maps have ids to 'name'/distinguish them. The client needs to match the cost map to the appropriate network map so it matches the network map id with the 'uses' property of the cost map.

Whoever publishes the IRD needs to ensure the URIs presented and any underlying servers/software/etc hand out consistent results otherwise that publisher's ALTO service isn't useful. How that is achieved is outside of the ALTO protocol.

Clients need to find the appropriate network map id to use if they are several in the IRD. How they find that is outside of the ALTO protocol. If ALTO providers publish multiple maps in an IRD without providing the user or client a mechanism (e.g. through getting a user to configure an appropriate name, or by using some other appropriate mechanism) that provider's/publisher's ALTO service isn't useful. How that is achieved is outside of the ALTO protocol.

So, yes ALTO providers/deployers need to be careful to ensure the service they offer is useful and ALTO clients need to offer ways for users (human or machine) to select which map id(s) are of interest to them but none of that requires work to the base ALTO protocol IMO.

Ben

On 15 Jul 2013, at 17:15, Wendy Roome wrote:

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

---

From: Wendy Roome <[email-masked]>
Date: Wed, 17 Jul 2013 15:33:47 -0400

I made that proposal before reading draft 17; otherwise I wouldn't have
bothered.

But if you equate "full network map id" to what I called "network map
name", draft 17 accomplishes exactly the same thing, minus the central
registry, and with different syntactic sugar.

BTW, that means that where before a client needed to be configured with
the uri for the IRD, now the client needs that plus the id name of a
network map.

I can see that leading to an interop problem down the road, though. I
suspect most ALTO servers have only one network map. Clients will be
tested against those servers, and will pick the IRD's one and only network
map. Because multiple network maps are rare, clients -- particularly
"upstream" clients that use an ALTO client library -- won't bother to
provide a hook to configure the network map id.

That will work fine until the client encounters a server with multiple
maps, and then the client will just randomly pick one. Or crash.

I don't think much can be done about that, though.

	- Wendy Roome

On 07/17/2013 15:12, "Ben Niven-Jenkins" <[email-masked]> wrote:

>Wendy, Colleagues,
>
>I simply do not think we need this level of complexity, registration or
>constraints. I see the world quite simply.
>
>We can have multiple network maps in an IRD so we agreed to allow maps
>have ids to 'name'/distinguish them. The client needs to match the cost
>map to the appropriate network map so it matches the network map id with
>the 'uses' property of the cost map.
>
>Whoever publishes the IRD needs to ensure the URIs presented and any
>underlying servers/software/etc hand out consistent results otherwise
>that publisher's ALTO service isn't useful. How that is achieved is
>outside of the ALTO protocol.
>
>Clients need to find the appropriate network map id to use if they are
>several in the IRD. How they find that is outside of the ALTO protocol.
>If ALTO providers publish multiple maps in an IRD without providing the
>user or client a mechanism (e.g. through getting a user to configure an
>appropriate name, or by using some other appropriate mechanism) that
>provider's/publisher's ALTO service isn't useful. How that is achieved is
>outside of the ALTO protocol.
>
>So, yes ALTO providers/deployers need to be careful to ensure the service
>they offer is useful and ALTO clients need to offer ways for users (human
>or machine) to select which map id(s) are of interest to them but none of
>that requires work to the base ALTO protocol IMO.
>
>Ben
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Jul 2013 21:03:18 +0100

We can reserve an id for a 'default' map the clients can fallback to. If there's demand for multiple maps and they provide value clients will provide hooks to select a map. If there isn't then none of this matters :-) Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 17 Jul 2013 17:01:48 -0400

Interesting deployment consideration and good suggestion on a default. Is
this default an attribute or an id? Does this default concept apply to only
network map or cost map as well, or more general any media type? From the
linking relationship, the structure will look like:

cost map 1 -> network map 1

cost map 2 -> network map 2

Hence, if the client uses cost map 2, it implies network map 2. So, default
is for cost map?

Thanks!

Richard

On Wednesday, July 17, 2013, Ben Niven-Jenkins wrote:

> We can reserve an id for a 'default' map the clients can fallback to. If
> there's demand for multiple maps and they provide value clients will
> provide hooks to select a map. If there isn't then none of this matters :-)
> Ben
>
> >>> is). As you get away from that