On Feb 10, 2009, at 4:35 PM, Laird Popkin wrote:
To agree with Saumitra, there's a difference between (1) a client measuring latency (for example) and (2) a p2p network asking for peer guidance based on optimizing latency.In the first case, the peer has to discover peers, and do latency tests with them, in order to discover which has the lowest latency, which is a slow process.In the second case, the p2p network asks for guidance to figure out which peers are lowest latency to which other peers, so that it can form connections to those peers. This is a fast process, because it doesn't require peer discovery or measurement, just a reference lookup against the ALTO guidance.- Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Saumitra Das" <[email protected]> To: "Laird Popkin" <[email protected]>, [email protected] Cc: [email protected]Sent: Tuesday, February 10, 2009 3:45:06 PM (GMT-0500) America/ New_YorkSubject: RE: [alto] differences among applicationsEach application on each host performing its own measurement is rather wasteful to network resources when a lot of such information can be aggregated or predicted using an iPlane-like ALTO service or some other measurement based ALTO service. While it may be more accurate it can also be timeconsuming specially if you are looking at available bandwidth type measurements. It may be possible for an ALTO service to predict the performance based on past behavior instead of having each application to measurements to each peer.I am not sure we would limit what the ALTO service returns to the user to be only abstract rules. As long as the query/response protocol can support it, The ALTO service should be able to return abstract things like Pdistance or more concrete metrics like latency. Is there a need for it to be required to be a specific way?I agree that the application should be free to use the guidance whichever way it chooses to.-Saumitra Qualcomm Research Santa Clara, CA -----Original Message-----From: [email protected] [mailto:[email protected]] On Behalf Of Laird PopkinSent: Tuesday, February 10, 2009 9:22 AM To: [email protected] Cc: [email protected] Subject: Re: [alto] differences among applicationsI wouldn't think that the application would query for the throughput and latency attributes of the network, but something slightly different, which is that when the application asks the ALTO server for guidance it would indicate that the application values latency/ throughput/etc., and the ALTO server would take that into account when providing guidance. The guidance, however, would only contain abstract rules (e.g. IP prefixes and "weights") guiding the application to optimize traffic, without any specific metrics.- Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Robert Raszuk" <[email protected]> To: "Laird Popkin" <[email protected]> Cc: "Eric Burger" <[email protected]>, [email protected]Sent: Tuesday, February 10, 2009 11:34:10 AM (GMT-0500) America/ New_YorkSubject: Re: [alto] differences among applications Hi Laird,attributes that it cares about (e.g. latency, throughput,Would application in fact query for the latency or throughput attributesor were just some examples ? I would imagine that actually those two could be measured by the application directly. In fact the application end to end measurement would be more accurate as it would include first and last hop links from/to the servers.But cost, localization, network/AS preference can not be easily measuredor self produced by the applications and those are where ALTO protocol does help. Do we have a list of those attributes already ? Cheers, R.Keep in mind that ALTO doesn't control the applications' peer assignment - it is a data source that provides guidance into the application. Ultimately the application uses that information, along with everything else that it knows, in order to determine its own optimal peer selection algorithm based on the specifics of the application. I would suggest that the application using ALTO should indicate what attributes that it cares about (e.g. latency, throughput, cost). The ALTO server can take this into account when providing guidance, if the ISP (or whoever is running the ALTO server) cares to do so. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Eric Burger" <[email protected]> To: "Song Haibin" <[email protected]> Cc: [email protected] Sent: Tuesday, February 10, 2009 8:52:45 AM (GMT-0500) America/New_York Subject: Re: [alto] differences among applications I would offer it is important to have the client specify what it thinks is important. However, I would also offer it would be fatal to have "Profile B", "Profile N", "Profile S" selection algorithms, where B, N, and S are different applications. I will guarantee that by the time we're done in the IETF, no one will case about those applications and will have moved on to some other, hot applications. It may be worth noting what parameters are important. On Feb 10, 2009, at 7:25 AM, stefano previdi wrote:On Feb 10, 2009, at 12:43 PM, Song Haibin wrote:I think it is necessary to discuss whether we need to standardize different peer selection algorithms according to different types of applications.We may want the alto protocol to allow the requester to specify which type of ranking/preference it needs. Note that this doesn't mean we need to standardize any algorithm. s.Best Regards, Haibin Email: [email protected] Skype: alexsonghw_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
