Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?
"Mingming Chen" <mingmingminne@126.com> Sat, 16 July 2016 02:57 UTC
Return-Path: <mingmingminne@126.com>
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 8223712D598 for <alto@ietfa.amsl.com>; Fri, 15 Jul 2016 19:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.286
X-Spam-Level:
X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=126.com
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 RRdbX-XcFWYY for <alto@ietfa.amsl.com>; Fri, 15 Jul 2016 19:57:32 -0700 (PDT)
Received: from m15-25.126.com (m15-25.126.com [220.181.15.25]) by ietfa.amsl.com (Postfix) with ESMTP id 92AD312D140 for <alto@ietf.org>; Fri, 15 Jul 2016 19:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=M9h9c IuWysyw2EURfFgtVK0Xc6q/FOBlbUYgC7mFNMk=; b=SV4gTKnLrxVk1IcfxesPM rOUocx2IhwClL7TxpaBuBYndjf3tE1rnmNBLIpbC+T/ipzRGo71EcqhEf9cYNmW0 7RBd/Ds/gD3iATIMpEcb9ZYACThIMEG66nRSyHNhxyD7MzX7pj5ptmLCShHsFP1k Q3U/uSnflnZ+0QX1SvSjBk=
Received: from mingmingminne$126.com ( [111.222.81.92] ) by ajax-webmail-wmsvr25 (Coremail) ; Sat, 16 Jul 2016 10:57:23 +0800 (CST)
X-Originating-IP: [111.222.81.92]
Date: Sat, 16 Jul 2016 10:57:23 +0800
From: Mingming Chen <mingmingminne@126.com>
To: Sebastian Kiesel <ietf-alto@skiesel.de>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160420(83524.8626) Copyright (c) 2002-2016 www.mailtech.cn 126com
In-Reply-To: <20160715151444.GC3919@gw01.ehlo.wurstkaes.de>
References: <D3AAB578.7DF072%w.roome@alcatel-lucent.com> <20160712210913.GM3915@gw01.ehlo.wurstkaes.de> <57884A02.3000207@mails.tsinghua.edu.cn> <20160715151444.GC3919@gw01.ehlo.wurstkaes.de>
X-CM-CTRLDATA: b/7VsmZvb3Rlcl9odG09NzAzNjo1Ng==
Content-Type: multipart/alternative; boundary="----=_Part_35400_1689665685.1468637843759"
MIME-Version: 1.0
Message-ID: <7401e56b.1894.155f1a3112f.Coremail.mingmingminne@126.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID: GcqowABHV+OUoolX1vg0AA--.41261W
X-CM-SenderInfo: 5plqwz5lqjzxxqqhqiyswou0bp/1tbikgSoiVag06F02gACsf
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/9dRu34yTbLe_yfxYL5musJ9_0M4>
Cc: IETF ALTO <alto@ietf.org>
Subject: Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?
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: Sat, 16 Jul 2016 02:57:34 -0000
Hi all, First, I agree with Kai : " >> I think whether to use the source/destination or to split up queries >> depends on the application. If it is selecting a destination for a >> given source, it certainly can choose XDOM-DISC(SRC). If the selection >> is about sources, probably XDOM-DISC(DST) is more reasonable. " Then, Xin's idea is reasonable for me. Suppose XDOM-DISC(X) just can get cost(X,*), an ALTO Client want to ask a reasonable cost(X,*) with a given X, it can achieve through XDOM-DISC(X), but when it want to ask a reasonable cost(*,Y) with a give Y, it should sent to all servers(except Y) to get the info, so I agree with Xin's here. XDOM-DISC(X) should register cost( X, *), cost(*,X), so it will save the query processor. Besides that, I think we can reduce some extra cost information of XDOM-DISC(X) by training in a specific situation(It depends on different applications and scene). When some cost information has not been called for a long time, we can consider to remove them to simplify cost data store. Then, a typo in 2.3, paragraph 2, line 3: and it is rooted in the in the special domain "IN-ADDR.ARPA." At 2016-07-15 23:14:44, "Sebastian Kiesel" <ietf-alto@skiesel.de> wrote: >Hi Kai and all, > >On Fri, Jul 15, 2016 at 10:27:14AM +0800, Gao Kai wrote: >> On 13/07/16 05:09, Sebastian Kiesel wrote: >> > On Tue, Jul 12, 2016 at 02:55:52PM -0400, Wendy Roome wrote: >> >> My comments on draft-kiesel-alto-xdom-disc-02: >> >> 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. >> >> I had the same question as Wendy because for me, sources and >> destinations are somewhat symmetric > >if src/dst and the costs between are really symmetric, it doesn't >make a difference. > >> so it is tempting to think there >> should be something like XDOM-DISC(X, Y), which might be overcomplicated >> though. > >That would be too complicated indeed. > > >> I think whether to use the source/destination or to split up queries >> depends on the application. If it is selecting a destination for a >> given source, it certainly can choose XDOM-DISC(SRC). If the selection >> is about sources, probably XDOM-DISC(DST) is more reasonable. > >I agree. So the idea is, that we call XDOM-DISC(X), in oder to find an >ALTO server that can answer both ECS queries, whether > >routingcost(src=X, dst=Y) > routingcost(src=X, dst=Z). > >and whether > >routingcost(src=Y, dst=X) > routingcost(src=Z, dst=X). > > >In other words, we use the common address X that appears in all the >tuples we want to compare as parameter for the XDOM-DISC. > >For the Endpoint Cost Service ECS, queries may have to be split in >a way that either the "srcs" or the "dsts" list in the query contains >only one IP address - and this address is used for XDOM-DISC. >What that means for the other ALTO services we still need to define. > >> If the >> application wants to pick the best source-destination pair, maybe the >> queries should never be split up. > >Not splitting the queries would be the best thing to do from an >optimization perspective. It would be great if there were >a bunch of ALTO servers all with the same knowledge, so we could >just discvover any one of them (e.g. using RFC7286) and ask it >arbitrary questions or download a comprehensive NxN cost map. >But for various reasons I believe that this is not going to happen >on an Internet scale (and after all, we are the Internet Engineering >Task Force ;) ). So we need to find a solution that works if knowledge >is partitioned. > >Thanks >Sebastian > >_______________________________________________ >alto mailing list >alto@ietf.org >https://www.ietf.org/mailman/listinfo/alto
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Y. Richard Yang
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Y. Richard Yang
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Mingming Chen
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Gao Kai
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Wendy Roome
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Gao Kai
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… wang xin
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Gao Kai
- Re: [alto] Adopting draft-kiesel-alto-xdom-disc a… Sebastian Kiesel
- [alto] Adopting draft-kiesel-alto-xdom-disc as WG… Wendy Roome
- [alto] Adopting draft-kiesel-alto-xdom-disc as WG… Vijay K. Gurbani