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

[Sebastian Kiesel <[e-mail]>]

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.



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

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