On Wed, Feb 1, 2012 at 8:50 AM, Sebastian Kiesel <[email protected]> wrote: > 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.
The current interpretation is: The ALTO protocol makes no statement on what entries in the cost map must or must not be filled in. It is assumed that if an entry is not there, the ALTO server did not wish to make a statement on the cost (either because it didn't know, or because it didn't want to tell you). IIRC, Vijay proposed an extension that would provide some more detail there, which was to indicate how certain the ALTO Server was in its answer. Certainly let us know if you think the protocol draft needs to make this clearer. > >> 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. In the CDN world (and other non-P2P cases) in some deployements there may be additional trust between the ALTO Server and ALTO Client. That opens up the possibility of exposing more fine-grained information, including something resembling the topology of the network. Yes, it is straying from the original context of P2P - but the charter now is open to CDN use cases too (and there is a mailing list for possible ALTO extensions which may or may not need rechartering :) ). Rich > > -- Sebastian > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
