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" <[email protected]> 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? >> > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
