Bill, all, On Wed, Feb 01, 2012 at 10:07:58AM -0500, Bill Roome wrote: > I guess I'm also late to this discussion. But I always assumed: > > 1. The ALTO costs are end-to-end. Always.
ack. > 2. An ALTO server is expected to give the costs between *every* pair of > PIDs. It can omit a cost only if it cannot determine that cost at all. My assumption was different: I'd say that the protocol specification must allow the ALTO server to return a full NxN matrix indicating all end-to-end costs between all N PIDs (maybe even different costs in the two directions between two given PIDs). But I also assume that in a real deployment we will rather have a very sparse matrix, with the default value "I don't know / I am not allowed to tell". I could even imagine that my ISP would operate an ALTO server, which gives my hosts only an 1xN vector, which tells me how "expensive" it is for me to reach all possible destinations in the Internet. > 3. You cannot infer a topology from the 'holes' in the cost map. ack. > 4. If it were possible to calculate the missing costs by using SPF (or > whatever) on the other costs, then the ALTO server should do that! The > ALTO server shouldn't push that task onto the clients. ack. Btw: which application needs to know the topology? If I remember correctly once upon a time our primary goal was assisting peer selection (i.e., I know that I can get the desired resource form IP address A, B, or C, so please ALTO service tell me which address I should give a connect()-try first). To that end, the 1xN vector would be enough. -- Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
