Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

[Sebastian Kiesel <[e-mail]>]

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 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.

Thanks
Sebastian