Sebastian, On Tuesday, July 19, 2016, Sebastian Kiesel <[email protected]> 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 <[email protected] > <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" <[email protected] > <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 > > > >[email protected] <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 > > > [email protected] <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 <[email protected] <javascript:;>> | > > | Professor of Computer Science | > > | http://www.cs.yale.edu/~yry/ | > > ===================================== > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
