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

[Sebastian Kiesel <[e-mail]>]

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.
For the "type 2" metrics, do you have a draft or other document in
mind, against which we could check the applicability?

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]>
> 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]> 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]
> >
> > >https://www.ietf.org/mailman/listinfo/alto
> >
> >
> >
> >
> >
> > _______________________________________________
> > alto mailing list
> > [e-mail]
> >
> > 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]>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================