Hi Tony, please see below.
On Tue, Dec 05, 2017 at 05:30:20AM +0000, xin wang wrote: > Dear Sebastian and all, > > > Thank you for the clarification! > > > First, I agree with your point that “the best source of information > for costs between source IP address S and destination address D, is > the network operator that runs the network in which S is located”, > which is quite natural and reasonable. My consideration is that what > is the best source of information really depends on the implementation > of reverse DNS where network operators put records for ALTO server > discovery. Therefore, it is possible that different network operator > may have different strategies to choose the best source of > information. You are right. Let me be more precise: Our assumption is not that those who control the reverse DNS for a prefix ALWAYS have the best ALTO information. Often it will be them, sometimes it could be someone else. We just assume that those who control the reverse DNS for a prefix always know who has the best information, and they can put a pointer to it in their DNS. > I think we should not restrict these network operators > with the same strategy. Instead, the protocol should define what the > best source (return of XDOMDISC(X,"ALTO:https")) would look like, I > think. For further discussion about the word "related" please see my other mail to qiao. Thanks, Sebastian > The following is my comments on Sec. 3: > > > For Sec. 3.1, as the list of IRD URI(s) is computed by > XDOMDISC(X,"ALTO:https”), I think it is acceptable that the result is very > sparse. We can see that the result basically captures all the cost values > related to “X” which satisfies the requirement of the ALTO client invoking > the service for “X”. > > > However, one thing not sure is that do we have a formal definition of > “related” in Sec. 2.1 where the definition of the interface is given? From > your draft, my understanding of “related” (i.e., the return of XDOMDISC) is > the following: > > > If an IRD contains an ALTO server which can give at least one useful cost > value either with “X” as a source or destination, then the URI of the IRD can > be returned for XDOMDISC(X,"ALTO:https”). > > > This definition can match the case 2 in Sec. 3.4 where the input of XDOMDISC > is the destination address. However, the definition would degrade the return > of XDOMDISC in the case 1 in Sec. 3.4 as in the extreme case for each > destination address Di, there is an ALTO server “related” to Di. Hence, the > return of XDOMDISC(S1,"ALTO:https”) would have n + 1 entities where n is the > number of destination addresses. Then, how to find the best one among these n > + 1 entities becomes a new issue. > > > One direct solution I can think of is that can we also add the “position” of > “X” as an additional input of XDOMDISC? The “position” field has three > possible values: “source”, “destination”, and “both" which means the > discovered ALTO server can give at least one useful cost value with “X” as > “source”, “destination”, and “both" respectively. Then, the interface would > be XDOMDISC(X, Position, "ALTO:https”). If this sounds reasonable, we can > then generalize the “position” field in a more abstract way if possible. > > > Best, > > X. Tony Wang > > > > ________________________________ > From: Sebastian Kiesel <[email protected]> > Sent: Monday, December 4, 2017 16:16 > To: xin wang > Cc: [email protected]; IETF ALTO > Subject: Re: Some questions for alto-xdom-disc > > Dear xin wang, all, > > please see below > > On Fri, Dec 01, 2017 at 04:05:47AM +0000, xin wang wrote: > > Dear authors of alto-xdom-disc and all, > > > > > > Do you have any new updates on the draft of alto-xdom-disc? > > we are working on a new version of the draft, which will give a better > specification of the discovery procedure as such (i.e., section 2). > We are not planning to make a change on how the procedure is supposed > to work, just give a better explanation. > > > > I know that the draft intends to address the IRD discovery issue in > > the cross-domain setting, but I find that the cross-domain itself > > arouse my great interest. > > Well, the immediate outcome of the procedure is one or more IRD URIs. > > However, nobody is interested in discovering IRDs as such - it is just > an intermediate step, so you can lookup the ECS or EPS in the IRD. > In fact, our procedure is intended to be used with the > Endpoint Property Service and the Endpoint Cost Service. > > > > Considering that each domain has one ALTO server that can give a > > useful cost value (not default) between any two endpoints in the > > domain for the ECS. Then, the ALTO server discovery works when a > > client asks for the cost value between any two endpoints in the same > > domain, as it will direct to the right ALTO server which can give cost > > values for some endpoint-pairs. It might involve multiple ALTO servers > > to answer a single query of ECS service but the requirement of the > > client can be satisfied. > > > > > > However, if a client asks for a cost value between two endpoints which > > locate in different domains, then who should be able to give the cost > > value? > > We believe that in many scenarios, the best source of information > for costs between source IP address S and destination address D, > is the network operator that runs the network in which S is located. > Consequently, we believe that this network operator should be able > to announce "if you want to do ECS(S,D) please ask the ALTO server > at http://...some.uri..."; > > > This should be a common case if we target to deploy ALTO across > > the public Internet as you listed as one of the requirements for ALTO > > cross-domain server discovery. > > Indeed. > > > There are basically two approaches for the issue above: one is to > > depend each ALTO server itself to compute cost values across domains > > (e.g., recursive sending queries to other servers); the other is to > > set up a hierarchy structure to relay the query to an upper ALTO > > server which is able to support ECS across domains. In either way, > > there need substantial efforts to consider/design a protocol between > > two ALTO servers (which is discussed a little in the Sec. 1.1.2 in > > your draft). > > > > Do you think there are potential solutions can resolve the issue > > without depending too much on the inter-ALTO-server information > > exchanging? Or design inter-ALTO-server protocol is the best > > direction? > > We do a classification and discussion of several approaches. > However, we then focus on one approach, which does not need any > communication between ALTO servers, neither using the regular ALTO > protocol nor a to-be-defined inter-ALTO-server protocol. > > Instead, we let the ALTO client do the work. > > If an ALTO client wants to query the ECS with specific source and > destination addresses, it has to discover an appropriate ALTO server > first. Then, it can ask this server, and this server is supposed to > answer without any consultation of other servers. > > Furthermore, we want to avoid that a new "rendezvous point" or > Internet-wide directory of ALTO servers would have to be established. > We want to build on an existing infrastructure. > > The idea is as follows: > > Conceptually, the ECS does a query on a large N x N matrix, > where the column headers are labeled "from IP address (or prefix)" and > the row headers are labeled "to IP address (or prefix)". > However, we believe that it is unlikely that a single ALTO server will > ever accumulate so much data that it can give reasonable values for > every element of the matrix, in an Internet-wide deployment scenario. > > Instead, we split our large matrix into many small 1 x N "column vectors". > Each of them indicates the cost from one specific IP address (or prefix) > to all possible IP addresses (or prefixes). Then, we can install each > of these column vectors on a different ALTO server. So, in total we can > have up to N ALTO servers, each with one stripe of the overall matrix. > Of course, one ALTO server can also host more than one column vector, so > we may work with fewer than N servers. > > Those who control the reverse DNS for S (i.e. the mapping from IP > address S to a host name) can put a record in the DNS pointing from S > to the URI of that ALTO server that knows the column vector > "from S to all possible IP addresses (or prefixes)". > This is how we use an existing infrastructure (the DNS) for the > discovery job. > > > > As I wrote above, we are working on an update to section 2. > Could you please review section 3, which explains the interaction > of the procedure with ECS and the other ALTO services? Thanks! > > > best regards, > Sebastian Viele Gruesse, Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
