I could imagine that an ALTO server operated by an ISP might mark costs to its own infrastructure as "authoritative" (because it knows its own network topology), and to other ISP's infrastructure as "non-authoritative" (because it only knows the network topology up to the interconnection with the other ISP or backbone).
Then some clients might filter out "non-authoritative" costs if these costs are considered less reliable. It may not as easy for clients to filter out such costs without some marking, because it doesn't normally know the topology of the ISP (eg does it use 1 AS number or many AS numbers?). Just a thought. -- Rich -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ben Niven-Jenkins Sent: Tuesday, August 30, 2011 9:56 AM To: Bill Roome Cc: [email protected] Subject: Re: [alto] Authoritative status of costs Colleagues, To add to what Bill has written below, I am also of the opinion that trying to add some indication of "authoritativeness" is futile. It would seem to only apply to cases where clients are speaking with multiple ALTO servers returning different costs for the same PIDs pairs so the client can normalise or otherwise distinguish which ALTO server's response is the one to 'trust' for a given PID/path because if a client only speaks to one ALTO server then inferred cost data is presumably preferable to no cost data (as the client can always ignore the data from the ALTO server anyway), no? In a case where different ALTO servers are returning different costs for the same PID pairs then an indication of "authoritative-ness" by itself doesn't help. If the answer to Bill's first question is "there is the need to help client identify what data it might want to treat as suspect" then a PID/cost property of "I-inferred-this-so-treat-with-caution" would do the job just as well with less ambiguity than some kind of "reliability" value IMO (assuming we adopt the concept of PID properties". Ben On 30 Aug 2011, at 14:26, Bill Roome wrote: > Basically, I think adding a "quality" modifier to the cost -- be it a > binary "authoritative vs non-" flag, or a continuous "reliablity" value -- > is an exercise in futility. > > Why? At best, the cost reported by an ALTO server is an indication of the > recent performance of the network. > > But clients don't care about past performance. Clients want to know the > FUTURE performance. And as they say in the stock market, "Past performance > is no guarantee of future performance." > > So even if the cost is a perfectly accurate completely authoritative > measure of the performance over the last few minutes, so what? As far as a > client is concerned, it is not an authoritative measure of what will > happen in the next few minutes, and cannot possibly be. > > I suggest that anyone who wants to add such a metric should also answer > two questions: > > * How would a client use that information? > * How would a server get the information -- especially a "reliability" > value? > > - Bill Roome > > On 08/27/2011 02:01, "[email protected]" <[email protected]> wrote: > >> Date: Sat, 27 Aug 2011 07:59:42 +0200 >> From: Enrico Marocco <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: [alto] Protocol issue: non-authoritative information >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> In order to fulfill the "server operated by a third-party" requirement, >> the ALTO protocol is designed in such a way to allow servers to provide >> cost information about networks they are not "authoritative" for. >> However, current specification does not provide a means for indicating >> some sort of reliability/accuracy level of the provided information. >> Such indication could be useful, for instance, in the case of a server >> operated by a network operator, when providing (guessed?) cost >> information about paths originating and terminating in networks it does >> not directly operate. >> >> (Related to this, is also the issue of a clearer specification of the >> server behavior when queried about information it does not have nor is >> willing to guess. This has been suggested to be addressed with the >> definition of a specific error code.) >> >> Possible options (please express and possibly motivate your preference): >> >> 1. do not add anything to the protocol and always assume that the >> server is fully confident in every piece of information it >> provides; >> >> 2. define a binary value field for indicating whether the server is >> authoritative for each network/pid it is providing cost >> information for; >> >> 3. define a discrete or continuous value field for the reliability of >> each piece of cost information provided in responses; >> >> 4. other. >> >> -- >> Ciao, >> Enrico >> > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
