>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Laird >Popkin >Sent: Wednesday, February 11, 2009 5:35 AM > >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.
I think option 1 will get accurate latency for each pair of peers at the time, while option 2 is simpler and faster. The usages for them are different. And for ALTO service, we will focus on option 2. BR Song Haibin >- 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_York >Subject: RE: [alto] differences among applications > >Each 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 >Popkin >Sent: Tuesday, February 10, 2009 9:22 AM >To: [email protected] >Cc: [email protected] >Subject: Re: [alto] differences among applications > >I 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_York >Subject: 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 attributes > or 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 measured >or 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
