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. On Jul 11, 2013 7:19 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. > > 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
