Hi Wendy, Personally, I prefer that we do not limit to one network map per IRD, because I see use cases where multiple network maps are more natural. In addition to use cases of different granularities, there are other use cases. One example is the CDN use case by Jan, where multiple network maps are helpful.
Here is some thinking on resolving the dependency/reference issue. - The objective of ALTO is to allow a network to provide information resources (IRs). Since we are RESTful based, we can consider each IR as a web page, if this helps with a mental model. - We distinguish two types of IRs: leaf IR: the data conveyed in such an IR does not refer to the data defined in another IR; non-leaf: a non leaf IR. For example, in the current ALTO information resources, network maps are leaf, but cost maps are not, because the definition of a cost map can refer to PIDs defined in a network map (or even maps, if we want to be aggressive). Given the cost map but not the network map, the client cannot "resolve" the values of all references (i.e., the values of PIDs). Now, build a dependency graph G of all ALTO information resources available by an ALTO Server (Service), where there is a link from IRa to IRb, iff the definition of IRa depends on some definition provided in IRb. We write such a dependency as IRa -> IRb. The objective of an IRD is to help IRa to find IRb. Assume that the dependency graph G has no loop. Then the ALTO service provider can compute many IRDs---an ALTO provider may not want to provide all IRs to a specify client. Specifically, assume that the network decides to provide a set S of IRs to some (class of) clients. Then, the network computes a (minimal) IRD through closure, i.e., - start the IRD containing the resources in S - if there is a path from an IR i in S to another IR in j in the dependency graph G, add j to the IRD One can see that an client obtaining the preceding IRD can resolve all definitions. The preceding dependency graph does reveal that there can be reference ambiguity, in the *general* case. For example, IRa -> IRb, and IRa -> IRc. But an item used in IRa may be defined in both IRb and IRc. As a made-up example, IRa is a cost map and refers to PIDs named "a", "b", "c"; IRb is a network map that defines PIDs named "a", and "b"; and IRc is another network map that defines PIDs named "a" and "c". Then IRa cannot resolve without ambiguity of the definition of "a". ALTO can solve such issues using more qualified names such as IRb.a to denote that it is the "a" defined in IRb. In the current spec, since the only dependency is from a cost map to only one network map (a cost map can specify "uses" for only one network map"), we do not have such an issue, but we can solve the issue if the more general information distribution structure is needed. Does this address the problems that you have in mind? Thanks! Richard On Fri, Jul 19, 2013 at 3:20 PM, Wendy Roome <[email protected]>wrote: > Folks, > > I'll explain my position one more time, and then I'll shut up. > > I think the "multiple network map" extensions in draft 17 do not help. > They do not provide any features that weren't available draft 16. All they > do is add complexity. I suggest rolling back to the draft 16 IRD > structure. > > Here's why. With draft 16, if a provider wanted to offer 3 network maps, > they'd provide 3 separate IRDs, one per network map. Say > http://www.myalto.com/map1/directory > http://www.myalto.com/map2/directory > http://www.myalto.com/map3/directory > A client would have to select the IRD via some mechanism that's beyond the > protocol. > > > In draft 17, the provider can put 3 network maps in one IRD, say > http://www.myalto.com/directory > But logically, the "id" & "uses" fields partition that IRD into 3 separate > service clusters, one per network map. There are no tie-ins between > clusters. Yes, the client only has to cope with one IRD, but it has to > pick one of the three network maps via some mechanism that's beyond the > protocol. > > I claim the only difference is that in -16, a client needed the IRD uri, > while in -17, a client needs that uri plus the network map name. In both > schemes, each network map has a name. It's just that in -16, the map name > is embedded in the IRD's uri, while in -17, the map name is additional > configuration data. So why is -17 any more powerful than -16? > > And because the -16 scheme was a lot simpler, I recommend reverting to > that. > > BTW, I think part of the problem was that somewhere along the way we > started to assume that a hostname can only have one IRD -- see the > examples. If you believe that, then it certainly makes sense to extend > IRDs to allow multiple network maps. But I see no reason for that > limitation. > > Apologies to those who spent a lot of work on draft 17, but that's how I > see it. And that's all I'll say in public unless someone asks. Private > discussions are welcome, of course. > > - Wendy Roome > > > > >Message: 2 > >Date: Fri, 19 Jul 2013 11:44:29 +0200 > >From: Sebastian Kiesel <[email protected]> > >Subject: Re: [alto] What is an ALTO server? > > > >Enrico, all, > > > >On Fri, Jul 19, 2013 at 10:50:47AM +0200, Enrico Marocco wrote: > >>On 7/19/13 10:30 AM, Sebastian Kiesel wrote: > >>> Sure. I know these paragraphs. But these would be compatible with all > >>> of the three definition approaches in my original mail (see below). > >>> So I am wondering whether we need a more precise definition. What is > >>> the unique thing that defines an individual ALTO server? The single > >>>IRD, > >>> the single network map, ...? > >>I may be missing something, but I actually don't get what we'd gain in > >>redefining concepts that are very common to most protocols, and in > >>particular to HTTP that ALTO builds on. > >>To turn the question around, what's the server when you open a web URL > >>in your browser? The L2 load balancer in front of the datacenter that > >>you'll hit first? The chain of reverse proxies you're likely going to > >>hit? The worker process putting together the biggest amount of bytes > >>that will go in the HTTP response you'll get in return? The virtual > >>machine on which such process runs? The physical box? > >>Again, I may be missing something, but this looks like a slippery slope > >>I'd rather not go to.. > > > >The point behind my question is, when I read the thread on costmap > >dependencies there are several statements what an ALTO server should > >(not) do or have, e.g. more than one network map. As an example, let me > >quote a mail from Wendy: > > > >>(1) I certainly agree that there is value in allowing a provider to offer > >>multiple network maps. I merely suggested that when provider does that, > >>we > >>regard each network map, and the associated cost services, as a different > >>ALTO Server. So if a provider has several network maps, they offer one > >>ALTO > >>*Service* with several separate ALTO *Servers*. > >[Message-ID: <ce05789e.7a631%[email protected]>] > > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
