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
