Hi Sebastian and all, On 16/07/16 05:19, Sebastian Kiesel wrote: > Hi Kai, > > On Sat, Jul 16, 2016 at 12:17:12AM +0800, Gao Kai wrote: >> 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 don't think that this idea will work in practice. LCP(X,Y) will most > often be outside of the in-addr.arpa. subtrees delegated to X's or Y's ISP. > Often, LCP(X,Y) will result in 0.0.0.0/0 - we would need some > "top-level ALTO server" or something like that? > > Our proposal is much easier to implement: > > If an IP address (or prefix) X belongs to an ISP or the IT department > of a company/university/etc., they should know the costs from X to all > other destinations in the Internet and vice versa. They can put them > in their ALTO server, i.e., that ALTO server will be able to answer whether > routingcost(src=X, dst=Y) > routingcost(src=X, dst=Z). > and whether > routingcost(src=Y, dst=X) > routingcost(src=Z, dst=X). > They can adjust their DNS so that XDOM-DISC(X) will find this ALTO > server. > > Of course, other ALTO servers operated by various parties may also know > information related to X, but XDOM-DISC(X) points to one IRD URI > endorsed by the ISP/operator of X. > > > > On the other hand, if you have a deployment scenario where > XDOM-DISC(LCP(X,Y)) makes sense, we don't need any change in > the specification of XDOM-DISC() and nobody will prevent you from > calling XDOM-DISC with the output from LCP. I have no intention to change the specification of XDOM-DISC, which I think is pretty clear. But it does occur to me that a shorter prefix may suggest the associated ALTO server has better knowledge on queries for end points in a larger range. > >>>> 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. > First, the whole section 3 does not use RFC2119 keywords. Its purpose > is to illustrate how this algorithm should be used. Other ways of > using XDOM-DISC are possible; nevertheless, our description should > not become too vague. > > Second, what do you mean with "judging the quality of ALTO services only > by their location is not very convincing."? > My view on this algorithm is that those people who control the reverse > DNS for a specific IP address or prefix X (i.e., usually an ISP or > IT department) can use the DNS to announce that if you want to optimize > traffic from or to X, you should use the indicated ALTO server. My apologies. I once questioned ([1]) about the meaning of the IP address used in the XDOM-DISC and how servers should register the DNS records but it's very clear now. I got the wrong impression because LIS is most likely to be looking for a nearby server. > > Thanks > Sebastian
Regards, Kai [1] https://mailarchive.ietf.org/arch/msg/alto/SbFtzE_Xen6wULDyt8Nmn5gLo28
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
