Subject: Re: [alto] Authoritative status of costs

From: Bill Roome <[email-masked]>
Date: Tue, 30 Aug 2011 09:26:52 -0400

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-masked]" <[email-masked]> wrote:

>Date: Sat, 27 Aug 2011 07:59:42 +0200
>From: Enrico Marocco <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: [alto] Protocol issue: non-authoritative information
>Message-ID: <[email-masked]>
>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
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 30 Aug 2011 14:55:46 +0100

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:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Bill Roome <[email-masked]>
Date: Tue, 30 Aug 2011 10:39:38 -0400

Ben raises an interesting point: do we expect clients will actually
contact multiple ALTO servers and compare the costs they return? That
never occurred to me. It does seem like a lot of effort for little gain.
I'm reminded of the old observation that "A man with one watch knows the
time of day. A man with two watches is never sure."

Also, comparing the costs from multiple ALTO servers only makes sense if
those servers use the same PID map. That implies those servers are tied
together administratively. And that in turn implies the servers are
probably getting their costs from the same underlying source, and
differences are most likely due to delays in propagating the cost
information to the servers.

That, in turn, implies that it might be useful if the ALTO server returned
an optional time-stamp for the cost data. The time stamp should be for the
overall cost map, not on individual pid-pair costs. Time stamps would be
arbitrary numbers, and would only be comparable for cost maps with the
same map-vtag. Higher value means "more recent."

	- Bill Roome

On 08/30/2011 09:55, "Ben Niven-Jenkins" <[email-masked]> wrote:

>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?
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 30 Aug 2011 17:06:32 +0100

Bill,

> time of day. A man with two watches is never sure."

:-)

I can think of use cases where a client may receive data from multiple ALTO servers, e.g. section 3.4 of draft-jenkins-alto-cdn-use-cases-01. What I'm not sure of right now is whether a client is likely to receive overlapping information and even if it does whether an approach more complex than "local import filtering/policies" on the client is required to overcome the overlapping data case.

My gut tells me that local policy/filtering is probably sufficient and some form of indicated "authoritative-ness" communicated in a cost map is likely to cause more confusion than any benefit it may bring.

Ben

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 30 Aug 2011 21:18:42 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Tuesday, August 30, 2011 9:56 AM
To: Bill Roome
Cc: [email-masked]
Subject: Re: [alto] Authoritative status of costs

Colleagues,

Ben