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

[wang xin <[e-mail]>]

Dear all,


For the first part, I think a key point is the cost(X, Y) should be kept at XDOM-DISC(X) or XDOM-DSIC(Y) or both. If only at XDOM-DISC(X), then it would become much complex for an ECS request like "give me all cost values with destination Y". It should ask all ALTO servers to get the result (here I assume cost(X, Y) != cost(Y, X)). It is the same for only at XDOM-DISC(Y). Hence, I think the cost(X, Y) should be kept at both servers.


Thanks,

Xin

________________________________
From: alto <[e-mail]> on behalf of Gao Kai <[e-mail]>
Sent: Friday, July 15, 2016 10:27:14 AM
To: Sebastian Kiesel; Wendy Roome
Cc: IETF ALTO
Subject: Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

Hi Sebastian, Wendy and all,

Please see below:

On 13/07/16 05:09, Sebastian Kiesel wrote:

Hi Wendy,

thanks for your review. please see below:


On Tue, Jul 12, 2016 at 02:55:52PM -0400, Wendy Roome wrote:


My comments on draft-kiesel-alto-xdom-disc-02:

Section 1:

You might mention that yet another problem with the 1.? solutions is that
the values of ALTO cost metrics are not standardized. For example, there
is no standard definition of what "routingcost 10" means. Hence cost
metric values are not comparable between ALTO servers.

This is also a problem for 2.1, because the client cannot tell if the
returned costs are from the server it contacted directly, or from some
other server.



Indeed, this is a problem with all approaches. Please see also
the discussion of 3.3. below.




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 so it is tempting to think there should be something like XDOM-DISC(X, Y), which might be overcomplicated though.

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.  If the application wants to pick the best source-destination pair, maybe the queries should never be split up.






Section 3.3:

This also has the problem that cost metric values are not standardized,
which will make it very difficult to merge costs from multiple ALTO
servers into a single cost map.



you are absolutely right.  So the "TBD" in this section is maybe
not to explain how this could be done, but more like explaining why
this is impossible unless we have a well-defined cost metric.




Also, I think you mean "NxN cost map" rather than "NxN network map".



right. (although inconsistent PID definitons among different ALTO servers
will add further headaches to the problem).




Section 4.2.1:

"or redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285])."

Does that refer to a root IRD referencing a secondary IRD, as described in
Section 9.2.4?



Not necessarily a "secondary" IRD, though this could be an option as
well.  I was thinking more of a dynamically generated IRD,  maybe
something like: if the client is from within our own network (maybe
using RFC 7286 to discover our server), return an IRD that points to a
fine grained PID map and many different cost maps, otherwise, if it
is a "foreign" client that discovered us using XDOM-DISC, return
an IRD that has a more coarse grained PID map and fewer cost maps.




If so, I don't think of a secondary IRD as representing a
different ALTO server. Rather, I regard secondary IRDs as distributing the
resources of one ALTO server over several physical processors. I assumed
that the set of resources from the root IRD and secondary IRDs were
managed by the same entity, and used the same cost metric definitions, so
that cost metric values obtained from any of those resources could be
safely compared with each other.



Hm. I need to think about that.  Did we define this, or is there text
that at least suggests that behavior?


Personally I think not only the secondary IRD, but also the entries in an IRD might be on another different ALTO server, where "different" means "hosted by different authorities".  It is technically possible that an ALTO server discovers other ALTO servers using XDOM-DISC and puts their IRD entries in its own directory.

I mean, if we see IRD as a directory in a file system, it is natural to think that there can be NFS directories (secondary directories pointing to another ALTO server) and symbolic links (IRD entries pointing to ALTO services on other ALTO servers).  As Sebastian suggests, we may make it clear that such behaviour should be avoided.

I would say we accept this, though, since the protocol does not provide any technical restriction on that.


But for the discussion of this draft, this is maybe not so important.
The idea behind xdom disc is, that if we cannot have a single omniscient
ALTO server a full NxN cost matrix with a consistent metric, we could at
least do some ranking (relative ordering) using queries like the one in
sec. 11.5.1.7. of RFC 7285, if operators publish their 1xN "cost
vectors" via their ALTO servers and the DNS. However, we need to be
aware that we cannot compare results of different queries.
Still better than nothing, if the "single omniscient server" scenario
turns out to be unrealistic, isn't it?



Thanks
Sebastian



Regards,
Kai