Hi Wendy, Thanks for your excellent ideas! Please see below.
On Thu, Jul 11, 2013 at 10:17 AM, Wendy Roome <[email protected]>wrote: > 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. > > 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 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 > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
