Re: [alto] Review on Cross-Domain Server Discovery

[wang xin <[e-mail]>]

Dear Sebastian,


For the first part, I think Section 2.3 and 2.4 can be treated as the extensions for RFC7286 to make it clear that how to support third-party server discovery. And this procedure is clear enough to me.


For the second part, I didn't find how the ALTO server should respond for that case (multi-domains) in RFC7285. I agree that S_X should know the cost from X to Y and the cost from X to Z. But this may indicate the cost is a global value.


Thanks,

Xin


________________________________
From: Sebastian Kiesel <[e-mail]>
Sent: Wednesday, July 13, 2016 4:12
To: wang xin
Cc: [e-mail]; IETF ALTO
Subject: Re: [alto] Review on Cross-Domain Server Discovery

Dear Xin,

thanks for the review! Please see below...

On Tue, Jul 12, 2016 at 04:03:57PM +0000, wang xin wrote:
> Dear authors,
>
>
> Here are my comments on your draft (https://tools.ietf.org/html/draft-kiesel-alto-xdom-disc-02).
>
>
> Section 2.3 that specifies how to construct domain names from IP
> address parameter makes it concrete for the supporting of "ALTO Cross
> Domain Server Discovery" which refers to "third-party server
> discovery" in the previous draft
> (https://tools.ietf.org/html/draft-kiesel-alto-3pdisc-05).

Why do you refer specifically to section 2.3?  Does your sentence

> I think people can be clear about how to get the URI of particular
> ALTO server's IRD based on the input IP address and service name from
> the draft.

cover the whole section 2, i.e., the full specification of the procedure?



> Section 3.2 that discusses how to support Endpoint Cost Service by the
> proposed solution might be not clear enough. Since one of the draft's
> background is multi-domain, it's easy to consider the source and
> destination of an ECS request reside in two different domains, each of
> which is allocated to different ALTO server. Then, in your example, X,
> Y, and Z may belong to three different ALTO servers, S_x, S_y, and
> S_z. The result (S_x) of parameter X doesn't have any information
> about Y and Z, and then it cannot complete the ECS request. One
> solution may be using aggregator
> (https://datatracker.ietf.org/doc/draft-bertz-alto-aggrimpl/). But, in
> this case, it should specify the mapping between URI, resource (or
> service) and domain name. Some resources (like Endpoint Property) may
> be in origin ALTO servers, others may be in the aggregator. But why
> don't point out that this draft doesn't consider this case for the
> simplicity? This draft really solves the third-party ALTO query of
> AR-33 (https://tools.ietf.org/html/rfc6708).

OK, so 3.2 needs more work.  The scenario I have in mind is as follows:

There are some hosts (e.g. peers of a p2p app) X, Y, Z located
in the networks of ISP_X, ISP_Y, ISP_Z, respectively.  Operator ISP_X
has an ALTO server S_X.

Then, there is some other host C located located in the network of
ISP_C, who operates ALTO server S_C.

For some reason, C wants to know the cost from X to Y and the cost
from X to Z  (for example, if C is a P2P tracker or a CDN redirector
processing some request from X, it might want to know the costs even if
it is not the endpoint of the bulk data transmission to be optimized).

But we assume that information is partitioned and S_C does not know the
cost from X to Y and the cost from X to Z.

Therefore, the ALTO client at C must use XDOM-DISC(X) to find S_X,
because S_X is supposed to know the cost from X to Y and the
cost from X to Z.



Does this make sense?

Thanks again,
Sebastian