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

Sebastian Kiesel <ietf-alto@skiesel.de> Tue, 12 July 2016 20:12 UTC

Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CBB12D62C for <alto@ietfa.amsl.com>; Tue, 12 Jul 2016 13:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjiE4eoNlj7o for <alto@ietfa.amsl.com>; Tue, 12 Jul 2016 13:12:26 -0700 (PDT)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91B812D62E for <alto@ietf.org>; Tue, 12 Jul 2016 13:12:14 -0700 (PDT)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1bN42K-00035g-Tz; Tue, 12 Jul 2016 22:12:08 +0200
Date: Tue, 12 Jul 2016 22:12:08 +0200
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: wang xin <xinwang2014@hotmail.com>
Message-ID: <20160712201208.GL3915@gw01.ehlo.wurstkaes.de>
References: <HK2PR03MB1714D5787FE951334B9EAB04A8300@HK2PR03MB1714.apcprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <HK2PR03MB1714D5787FE951334B9EAB04A8300@HK2PR03MB1714.apcprd03.prod.outlook.com>
Accept-Languages: en, de
Organization: my personal mail account
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/tRweK18aU72WjPAN9upDo5uytWQ>
Cc: "mls.ietf@gmail.com" <mls.ietf@gmail.com>, IETF ALTO <alto@ietf.org>
Subject: Re: [alto] Review on Cross-Domain Server Discovery
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 20:12:28 -0000

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