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

[Gao Kai <[e-mail]>]

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