Re: [alto] Some questions for alto-xdom-disc
Sebastian Kiesel <ietf-alto@skiesel.de> Mon, 04 December 2017 21:16 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 4EB23126DD9; Mon, 4 Dec 2017 13:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] 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 1R8RacLIHcPN; Mon, 4 Dec 2017 13:16:50 -0800 (PST)
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 F1963124BAC; Mon, 4 Dec 2017 13:16:49 -0800 (PST)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1eLy6Y-0006E4-Bf; Mon, 04 Dec 2017 22:16:46 +0100
Date: Mon, 04 Dec 2017 22:16:46 +0100
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: xin wang <xinwang2014@hotmail.com>
Cc: "draft-ietf-alto-xdom-disc@ietf.org" <draft-ietf-alto-xdom-disc@ietf.org>, IETF ALTO <alto@ietf.org>
Message-ID: <20171204211646.GA3544@gw01.ehlo.wurstkaes.de>
References: <DM2PR08MB1337AE2BC4D503AB8FDCC506A8390@DM2PR08MB1337.namprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM2PR08MB1337AE2BC4D503AB8FDCC506A8390@DM2PR08MB1337.namprd08.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/dZDCWcO5KFxd-_edHs_2qK53s2U>
Subject: Re: [alto] Some questions for alto-xdom-disc
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 04 Dec 2017 21:16:52 -0000
Dear xin wang, all, please see below On Fri, Dec 01, 2017 at 04:05:47AM +0000, xin wang wrote: > Dear authors of alto-xdom-disc and all, > > > Do you have any new updates on the draft of alto-xdom-disc? we are working on a new version of the draft, which will give a better specification of the discovery procedure as such (i.e., section 2). We are not planning to make a change on how the procedure is supposed to work, just give a better explanation. > I know that the draft intends to address the IRD discovery issue in > the cross-domain setting, but I find that the cross-domain itself > arouse my great interest. Well, the immediate outcome of the procedure is one or more IRD URIs. However, nobody is interested in discovering IRDs as such - it is just an intermediate step, so you can lookup the ECS or EPS in the IRD. In fact, our procedure is intended to be used with the Endpoint Property Service and the Endpoint Cost Service. > Considering that each domain has one ALTO server that can give a > useful cost value (not default) between any two endpoints in the > domain for the ECS. Then, the ALTO server discovery works when a > client asks for the cost value between any two endpoints in the same > domain, as it will direct to the right ALTO server which can give cost > values for some endpoint-pairs. It might involve multiple ALTO servers > to answer a single query of ECS service but the requirement of the > client can be satisfied. > > > However, if a client asks for a cost value between two endpoints which > locate in different domains, then who should be able to give the cost > value? We believe that in many scenarios, the best source of information for costs between source IP address S and destination address D, is the network operator that runs the network in which S is located. Consequently, we believe that this network operator should be able to announce "if you want to do ECS(S,D) please ask the ALTO server at http://...some.uri..." > This should be a common case if we target to deploy ALTO across > the public Internet as you listed as one of the requirements for ALTO > cross-domain server discovery. Indeed. > There are basically two approaches for the issue above: one is to > depend each ALTO server itself to compute cost values across domains > (e.g., recursive sending queries to other servers); the other is to > set up a hierarchy structure to relay the query to an upper ALTO > server which is able to support ECS across domains. In either way, > there need substantial efforts to consider/design a protocol between > two ALTO servers (which is discussed a little in the Sec. 1.1.2 in > your draft). > > Do you think there are potential solutions can resolve the issue > without depending too much on the inter-ALTO-server information > exchanging? Or design inter-ALTO-server protocol is the best > direction? We do a classification and discussion of several approaches. However, we then focus on one approach, which does not need any communication between ALTO servers, neither using the regular ALTO protocol nor a to-be-defined inter-ALTO-server protocol. Instead, we let the ALTO client do the work. If an ALTO client wants to query the ECS with specific source and destination addresses, it has to discover an appropriate ALTO server first. Then, it can ask this server, and this server is supposed to answer without any consultation of other servers. Furthermore, we want to avoid that a new "rendezvous point" or Internet-wide directory of ALTO servers would have to be established. We want to build on an existing infrastructure. The idea is as follows: Conceptually, the ECS does a query on a large N x N matrix, where the column headers are labeled "from IP address (or prefix)" and the row headers are labeled "to IP address (or prefix)". However, we believe that it is unlikely that a single ALTO server will ever accumulate so much data that it can give reasonable values for every element of the matrix, in an Internet-wide deployment scenario. Instead, we split our large matrix into many small 1 x N "column vectors". Each of them indicates the cost from one specific IP address (or prefix) to all possible IP addresses (or prefixes). Then, we can install each of these column vectors on a different ALTO server. So, in total we can have up to N ALTO servers, each with one stripe of the overall matrix. Of course, one ALTO server can also host more than one column vector, so we may work with fewer than N servers. Those who control the reverse DNS for S (i.e. the mapping from IP address S to a host name) can put a record in the DNS pointing from S to the URI of that ALTO server that knows the column vector "from S to all possible IP addresses (or prefixes)". This is how we use an existing infrastructure (the DNS) for the discovery job. As I wrote above, we are working on an update to section 2. Could you please review section 3, which explains the interaction of the procedure with ECS and the other ALTO services? Thanks! best regards, Sebastian
- [alto] Some questions for alto-xdom-disc xin wang
- Re: [alto] Some questions for alto-xdom-disc Sebastian Kiesel
- Re: [alto] Some questions for alto-xdom-disc Qiao Xiang
- Re: [alto] Some questions for alto-xdom-disc xin wang
- Re: [alto] Some questions for alto-xdom-disc Sebastian Kiesel
- Re: [alto] Some questions for alto-xdom-disc Sebastian Kiesel