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

From: wang xin <[email-masked]>
Date: Tue, 12 Jul 2016 16:03:57 +0000

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). 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.

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).

Thanks,

Xin

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 12 Jul 2016 22:12:08 +0200

Dear Xin,

thanks for the review! Please see below...

On Tue, Jul 12, 2016 at 04:03:57PM +0000, wang xin wrote:
> 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

---

From: wang xin <[email-masked]>
Date: Wed, 13 Jul 2016 09:11:00 +0000

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 <[email-masked]>
Sent: Wednesday, July 13, 2016 4:12
To: wang xin
Cc: [email-masked]; IETF ALTO
Subject: Re: [alto] Review on Cross-Domain Server Discovery

Dear Xin,

Does this make sense?

Thanks again,
Sebastian