Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

Sebastian Kiesel <ietf-alto@skiesel.de> Tue, 19 July 2016 21:28 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 58CAD12D930 for <alto@ietfa.amsl.com>; Tue, 19 Jul 2016 14:28:41 -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 i86iddrZ2BFU for <alto@ietfa.amsl.com>; Tue, 19 Jul 2016 14:28:39 -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 A4C5B12D937 for <alto@ietf.org>; Tue, 19 Jul 2016 14:28:38 -0700 (PDT)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1bPcZ6-0008JI-Um; Tue, 19 Jul 2016 23:28:32 +0200
Date: Tue, 19 Jul 2016 23:28:32 +0200
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Message-ID: <20160719212832.GK3919@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> <7401e56b.1894.155f1a3112f.Coremail.mingmingminne@126.com> <CANUuoLoy7sPE2LBukWebYKHSCQ2Dae7YU_GRwkpNoF4d62ea_Q@mail.gmail.com> <20160719133624.GG3919@gw01.ehlo.wurstkaes.de> <CANUuoLr+bOxVHWowmQGAJchJ2=33kdQyx4_52DX4+_SuOOctmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANUuoLr+bOxVHWowmQGAJchJ2=33kdQyx4_52DX4+_SuOOctmg@mail.gmail.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/PC6yzbi2mpigc75739xtowWHXdM>
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: Tue, 19 Jul 2016 21:28:41 -0000

Hi Richard,

On Tue, Jul 19, 2016 at 04:27:41PM -0400, Y. Richard Yang wrote:
> Sebastian,
> 
> On Tuesday, July 19, 2016, Sebastian Kiesel <ietf-alto@skiesel.de> wrote:
> 
> > Hi Richard,
> >
> > our proposal aims at the "routingcost" metric we have in our base
> > protocol spec and at all the "type 1" metics in your classification.
> 
> 
> This is a good starting point.
> 
> 
> > For the "type 2" metrics, do you have a draft or other document in
> > mind, against which we could check the applicability?
> >
> > I do not, and can try to work on one soon :-)

Hm, that was not quite the answer I was hoping to get.
To me, XDOM-DISC is the one missing piece to "ALTO 1.0" as we envisioned
it some years ago.

What you envision with the "type 2" metrics is maybe not one, but
several steps beyond that.  Of course, if we had a rather consistent
view among WG members about these next steps (and ideally a non -00
draft for a chartered deliverable), we should take that into
consideration.  Given the current state of the "type 2" idea, I'd prefer
to quickly finalize XDOM-DISC a companion document to RFC 7285 and then
see what's next.

Sebastian


> > On Mon, Jul 18, 2016 at 08:44:22PM -0400, Y. Richard Yang wrote:
> > > Hi all,
> > >
> > > It sure is a good thread of discussions. Here is a bit more thought.
> > >
> > > Consider traffic from X1 -> Y1 with a given routing path. In a general
> > > setting, the path will traverse a set of network devices,
> > > contributed/funded by a set of network service providers (NSPs). There
> > can
> > > be a set of properties/metrics associated with the path X1->Y1, e.g.,
> > > routing-cost(X1->Y1), propagation-delay(X1->Y1), and we can identify two
> > > types:
> > >
> > > - Type 1: Some of the metrics can be "objective" or "universal" if we
> > want
> > > a slightly more neutral word. For example, propagation delay is one, in
> > > that there should be a single value, although different entities may have
> > > different estimation of the (true) value.
> > >
> > > - Type 2: Some of the metrics can be more "subjective", and an example is
> > > routing cost, in that it probably should be a vector, with at least one
> > > assigned value from the aspect of each NSP contributing its resources in
> > > the path.
> > >
> > > For a Type 1 metric, different ALTO servers should give the same value of
> > > m1(X1->Y1), and if two servers give two different values, something is
> > > wrong.
> > >
> > > For a Type 2 metric, different ALTO servers may inherently be giving
> > their
> > > different aspects (components of the vector), and hence it can be
> > > reasonable that the client, who is in control, chooses whose aspect(s) it
> > > considers. The client may choose to discover and get as many aspects, for
> > > those on the path, as possible and make a tradeoff, or consider only a
> > > single aspect. In other words, a key issue is to discover those who
> > > can/want to share an aspect on such a metric. My sense is that some
> > > systematic analysis of potential stake-holder scenarios can be helpful,
> > > when designing the important xdom mechanism.
> > >
> > > Richard
> > >
> > >
> > > On Fri, Jul 15, 2016 at 10:57 PM, Mingming Chen <mingmingminne@126.com
> > <javascript:;>>
> > > wrote:
> > >
> > > > 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
> > <javascript:;>> 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 <javascript:;>
> > > >
> > > > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwIBAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=kWZaV319Ac-B7cDmzmre5DaIXwFd4sUR0alUPVIjAh0&s=wn7taG7TWwfDJIr8ua-WFZCDidS0uII4kqgZbX2MkNU&e=
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > alto mailing list
> > > > alto@ietf.org <javascript:;>
> > > >
> > > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=_oBdiZa8lfE8dhoB5OrQnvZet95uHVboRGpQLFNgYwU&s=VQN7JZNuLze-wcZOmB0fmNHbLQX88bZnjAL9qdFSakU&e=
> > > >
> > > >
> > >
> > >
> > > --
> > > --
> > >  =====================================
> > > | Y. Richard Yang <yry@cs.yale.edu <javascript:;>>   |
> > > | Professor of Computer Science       |
> > > | http://www.cs.yale.edu/~yry/        |
> > >  =====================================
> >
> 
> 
> -- 
> Richard