Hi Sebastian, Wendy and all, Please see below:
On 13/07/16 05:09, Sebastian Kiesel wrote: > Hi Wendy, > > thanks for your review. please see below: > > > On Tue, Jul 12, 2016 at 02:55:52PM -0400, Wendy Roome wrote: >> My comments on draft-kiesel-alto-xdom-disc-02: >> >> Section 1: >> >> You might mention that yet another problem with the 1.? solutions is that >> the values of ALTO cost metrics are not standardized. For example, there >> is no standard definition of what "routingcost 10" means. Hence cost >> metric values are not comparable between ALTO servers. >> >> This is also a problem for 2.1, because the client cannot tell if the >> returned costs are from the server it contacted directly, or from some >> other server. > Indeed, this is a problem with all approaches. Please see also > the discussion of 3.3. below. > > >> Section 3.2: >> >> If a client wants the cost from X => Y, why just do cross-domain discovery >> on address X? Why not do it for Y instead? Or do it for both X & Y? > This is again to cope with the not so well-defined "routingcost" metric. > > Our assumtion is that XDOM-DISC(X) will discover one ALTO server, > which will be able to express costs (X,Y) and costs (X,Z) using a > (locally) consistent routingcost metric, i.e., with the meaning that > a lower value indicates a higher preference. > > If we used XDOM-DISC(Y) and XDOM-DISC(Z) we would probably discover > two servers, which could use completely incompatible definitions. > > > In other words, the example query given in sec. 11.5.1.7. of RFC 7285 > should be sent to the server yielded from XDOM-DISC(192.0.2.2). > > If the "srcs" list contained more than one IP address, the query > should be split up in several queries, each containing only one > IP address in "srcs" (but keep all in "dsts"), and each of these > "sub-queries" would need its own call to XDOM-DISC. I had the same question as Wendy because for me, sources and destinations are somewhat symmetric so it is tempting to think there should be something like XDOM-DISC(X, Y), which might be overcomplicated though. I think whether to use the source/destination or to split up queries depends on the application. If it is selecting a destination for a given source, it certainly can choose XDOM-DISC(SRC). If the selection is about sources, probably XDOM-DISC(DST) is more reasonable. If the application wants to pick the best source-destination pair, maybe the queries should never be split up. > > >> Section 3.3: >> >> This also has the problem that cost metric values are not standardized, >> which will make it very difficult to merge costs from multiple ALTO >> servers into a single cost map. > you are absolutely right. So the "TBD" in this section is maybe > not to explain how this could be done, but more like explaining why > this is impossible unless we have a well-defined cost metric. > > >> Also, I think you mean "NxN cost map" rather than "NxN network map". > right. (although inconsistent PID definitons among different ALTO servers > will add further headaches to the problem). > > >> Section 4.2.1: >> >> "or redirect the client to another ALTO server using mechanisms of the >> ALTO protocol (see Sect. 9 of [RFC7285])." >> >> Does that refer to a root IRD referencing a secondary IRD, as described in >> Section 9.2.4? > Not necessarily a "secondary" IRD, though this could be an option as > well. I was thinking more of a dynamically generated IRD, maybe > something like: if the client is from within our own network (maybe > using RFC 7286 to discover our server), return an IRD that points to a > fine grained PID map and many different cost maps, otherwise, if it > is a "foreign" client that discovered us using XDOM-DISC, return > an IRD that has a more coarse grained PID map and fewer cost maps. > > >> If so, I don't think of a secondary IRD as representing a >> different ALTO server. Rather, I regard secondary IRDs as distributing the >> resources of one ALTO server over several physical processors. I assumed >> that the set of resources from the root IRD and secondary IRDs were >> managed by the same entity, and used the same cost metric definitions, so >> that cost metric values obtained from any of those resources could be >> safely compared with each other. > Hm. I need to think about that. Did we define this, or is there text > that at least suggests that behavior? Personally I think not only the secondary IRD, but also the entries in an IRD might be on another different ALTO server, where "different" means "hosted by different authorities". It is technically possible that an ALTO server discovers other ALTO servers using XDOM-DISC and puts their IRD entries in its own directory. I mean, if we see IRD as a directory in a file system, it is natural to think that there can be NFS directories (secondary directories pointing to another ALTO server) and symbolic links (IRD entries pointing to ALTO services on other ALTO servers). As Sebastian suggests, we may make it clear that such behaviour should be avoided. I would say we accept this, though, since the protocol does not provide any technical restriction on that. > But for the discussion of this draft, this is maybe not so important. > The idea behind xdom disc is, that if we cannot have a single omniscient > ALTO server a full NxN cost matrix with a consistent metric, we could at > least do some ranking (relative ordering) using queries like the one in > sec. 11.5.1.7. of RFC 7285, if operators publish their 1xN "cost > vectors" via their ALTO servers and the DNS. However, we need to be > aware that we cannot compare results of different queries. > Still better than nothing, if the "single omniscient server" scenario > turns out to be unrealistic, isn't it? > > > > Thanks > Sebastian > Regards, Kai
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
