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

["Y. Richard Yang" <[e-mail]>]

Sebastian,

On Tuesday, July 19, 2016, Sebastian Kiesel <[e-mail]> 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 :-)

Thanks a lot for the good work!
Richard

Thanks
> 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 <[e-mail]
> <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" <[e-mail]
> <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
> > > >[e-mail] <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
> > > [e-mail] <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 <[e-mail] <javascript:;>>   |
> > | Professor of Computer Science       |
> > | http://www.cs.yale.edu/~yry/        |
> >  =====================================
>


-- 
Richard