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

[Gao Kai <[e-mail]>]

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