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

From: Wendy Roome <[email-masked]>
Date: Thu, 11 Jul 2013 10:17:00 -0400

I was out for a while, and I've just caught up on this discussion. I
assume you've all seen it, so I won't quote the discuss.

Let me suggest something very usual for me: a simplification! Namely, I
suggest that we decree that

"An ALTO Server consists of one, and only one, Network Map, and one or
more Cost Maps that depend on that Network Map."

A service provider can still provide several different Network Maps, say
with different levels of detail. They just become logically separate ALTO
Servers, each with its own set of cost maps. The provider can still offer
them on the same physical server, but with different URIs.

That begs the question of how we define an "ALTO Server". Here are two
possibilities:

1. An "ALTO Server" is one, and only one, IRD. This means every IRD must
provide a network map service entry. In the example in {8.5},
alto.example.com & custom.alto.example.com would be separate ALTO servers,
and we'd have to add a network map service entry to the
custom.alto.example.com IRD. That could be the network map URI on
alto.example.com, or it could be a URI on the custom.alto.example.com
machine for the version of the network map that corresonds to the
custom.alto.example.com cost services.

   *or*

2. An "ALTO Server" is all services defined by an IRD and the tree of IRDs
reachable from it. The IRD tree may have several entries for Network Map
services (either full or filtered), possibly with different URIs, but they
should all return the same Network Map. This is more general, but it leads
to the concepts of "parent" & "child" IRDs, and it implies that the
network map service should be defined in the top-level IRD. It also means
network map updates should be atomic over all services. That is, when the
network map is updated with a new vtag, every cost service in the tree
should return that same vtag. There shouldn't be any "lag".

I prefer #1, because it's simpler, and each IRD is self-contained &
complete. If you're worried about coupling, remember that cost services
are inherently tightly coupled to the network map they use. I don't see
any way around that. I suspect that anyone who actually provides ALTO
services will end up defining all the cost services for the same network
map in the same IRD anyway.  Take the {8.5} example. I see two reasons for
splitting the services between two physical servers. One is to spread the
load. The same organization runs both servers, defines the common network
map, and ensures that the servers are synchronized. BTW, in this case, I
don't see why that organization would bother to use two IRDs. It would be
simpler to define all the services in a single IRD.

The second reason for having two physical servers in {8.5} is they're run
by two separate groups. The first defines a network map, and provides
basic cost services, while the second group provides advanced cost
services. When the first group revises the network map, they "throw it
over the wall" to the second group, who then update their cost services on
their own schedule. In this case, it makes sense for
custom.alto.example.com to provide its own Network Map URI, with the
version that corresponds to its cost services. The second group ensures
that their cost services stay in sync with their version of the network
map, but that can lag the "alto.example.com"'s version of the network map.

Oh yes, I assume that vtags is are globally unique IDs. Whether a provider
does that by using UUIDs, or domain names and time stamps, is up to the
provider. But the bottom line is that if a client receives a Network Map
and a Cost Map with the same vtag, then that Cost Map MUST correspond to
that Network Map, regardless of where they came from.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 11 Jul 2013 13:39:57 -0400

Hi Wendy,

Thanks for your excellent ideas! Please see below.

> map, but that can lag the "alto.example.com"'s version of the network map.
Let me better understand your second setting. Assume that the time is t.

If a client fetches a network map from alto.example.com, the client can get
a
network map with vtag n+1.

If the client fetches the cost map from custom.alto.example.com, the client
gets
a cost map, whose network map vtag can be n (the version that the second
group
still uses). The client cannot fetch the network map from alto.example.com,
unless
we support a version system, but the client can fetch from the network map
at
custom.alto.example.com.

I believe that the preceding is what you have in mind.

This insight of using network-map snapshot, by the second group, in your
example,
for consistency is a very nice idea. I know one major software company
depends
on snapshots of packages for better consistency efficiency.

Hence, ALTO should support this feature as well.

Whether we should make the decision that each ALTO Server can define only
one
network map is still not clear. A single net map is indeed simpler. A
question is
whether we may may encounter use cases with a large number of topologies
(network maps). Do you have any data points or thinking here?

Thanks!

Richard

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

---

From: Richard Alimi <[email-masked]>
Date: Fri, 12 Jul 2013 00:17:49 -0700

Hi Wendy,

Thanks for the feedback.

Two quick comments:
(1) I think there is value in allowing multiple network maps for an ALTO
Server, all being served under the same hostname.  it may be "cheap" to use
a new hostname, but at that point I believe a restriction of one network
map per hostname would reduce the flexibility when it comes to deployment.
  We have tried hard to keep the ALTO protocol flexible by just identifying
resources by URIs and avoiding ties to a particular hostname.  I see the
fact that an "ALTO Server' is not tied to a single hostname as a feature.

(2) I think we should avoid requirements on atomicity, but instead be
satisfied with eventual consistency.  If updates are happening so
frequently that ALTO Clients are not converging (e.g., the network map is
updating too frequently), then we probably need the notification extensions
that have been discussed.

---

From: Wendy Roome <[email-masked]>
Date: Fri, 12 Jul 2013 10:38:17 -0400

Here's one use case: Map1 is coarse-grained with a small number of PIDs.
Map2 is much more detailed.

In this case, I'd think the provider might like to offer Map1 to the public,
but limit Map2 to trusted clients -- possibly requiring Map2 clients to
present a client certificate. In that case, I'd expect that the provider
would want to offer those services on  separate servers.

- Wendy 

From:  "Y. Richard Yang" <[email-masked]>
Date:  Thu, July 11, 2013 13:39
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] Clarifying Cost Map Dependencies on a Network Map

---

From: Wendy Roome <[email-masked]>
Date: Fri, 12 Jul 2013 10:51:02 -0400

Exactly.  The Network Map service on custom.alto.example.com should return
the same vtag as the cost services in that IRD.  Eventually the Network Map
services on custom.alto.example.com and alto.example.com should return the
same map, with the same vtag, but it might lag for a few days, because it
requires human intervention to reconcile them.

- Wendy Roome

If a client fetches a network map from alto.example.com
<http://alto.example.com> , the client can get a
network map with vtag n+1.

If the client fetches the cost map from custom.alto.example.com
<http://custom.alto.example.com> , the client gets
a cost map, whose network map vtag can be n (the version that the second
group
still uses). The client cannot fetch the network map from alto.example.com
<http://alto.example.com> , unless
we support a version system, but the client can fetch from the network map
at
custom.alto.example.com <http://custom.alto.example.com> .

---

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

Here's another take on that. Suppose one IRD offers two different Network
Map services.

How does a client know which one to use?  Unless I missed it, nothing in the
protocol distinguishes between them. The client would need guidance from the
provider, outside of the protocol.  So they might as well be two different
servers, in two different IRDs. At least that makes it obvious that a client
needs non-protocol information from the provider to decide which server/IRD
to use.

- Wendy Roome