Re: [alto] Authoritative status of costs

[Ben Niven-Jenkins <[e-mail]>]

Bill,

On 30 Aug 2011, at 15:39, Bill Roome wrote:

> 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."

:-)

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


> 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" <[e-mail]> 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?
>> 
> 
>