Hi Sebastian and all, On 15/07/16 23:14, Sebastian Kiesel wrote: > Hi Kai and all, > > On Fri, Jul 15, 2016 at 10:27:14AM +0800, Gao Kai wrote: >> On 13/07/16 05:09, Sebastian Kiesel wrote: >>> On Tue, Jul 12, 2016 at 02:55:52PM -0400, Wendy Roome wrote: >>>> My comments on draft-kiesel-alto-xdom-disc-02: >>>> 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 > if src/dst and the costs between are really symmetric, it doesn't > make a difference. > >> so it is tempting to think there >> should be something like XDOM-DISC(X, Y), which might be overcomplicated >> though. > That would be too complicated indeed. Actually my first feeling is that may be we can use XDOM-DISC(LCP(X,Y)) where LCP stands for longest common prefix. This can be extended to multiple addresses, for example, use the ALTO server XDOM-DISC(LCP(X, Y, Z)) for both scenarios described below. >> 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. > I agree. So the idea is, that we call XDOM-DISC(X), in oder to find an > ALTO server that can answer both ECS queries, whether > > routingcost(src=X, dst=Y) > routingcost(src=X, dst=Z). > > and whether > > routingcost(src=Y, dst=X) > routingcost(src=Z, dst=X). > > > In other words, we use the common address X that appears in all the > tuples we want to compare as parameter for the XDOM-DISC. Yes. Also, I think maybe it is better to change the tone a bit with "SHOULD"/"MIGHT" to indicate preferences instead of "MUST"/"HAVE TO" which make it a rule, because judging the quality of ALTO services only by their location is not very convincing. > > For the Endpoint Cost Service ECS, queries may have to be split in > a way that either the "srcs" or the "dsts" list in the query contains > only one IP address - and this address is used for XDOM-DISC. > What that means for the other ALTO services we still need to define. > >> If the >> application wants to pick the best source-destination pair, maybe the >> queries should never be split up. > Not splitting the queries would be the best thing to do from an > optimization perspective. It would be great if there were > a bunch of ALTO servers all with the same knowledge, so we could > just discvover any one of them (e.g. using RFC7286) and ask it > arbitrary questions or download a comprehensive NxN cost map. > But for various reasons I believe that this is not going to happen > on an Internet scale (and after all, we are the Internet Engineering > Task Force ;) ). So we need to find a solution that works if knowledge > is partitioned. > > Thanks > Sebastian
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
