(continuing the discussion) I acknowledge that we all seem to have some preconceived notions about how particular aspects of this should work. This scheme (below) includes some of my expectations.
The clients could query service providers for resource availability, using a multicast with some initial IGMP hop limit (i.e. time to live, or TTL) setting. Any service providers within this TTL range could respond with their resource availability (as queried), and include the hop limit of the request when the query was received. The client could then discriminate between multiple service providers to determine an optimal service provider, in terms of network proximity (router hops), response time (as measured), or resource availability at the service providers. Or, the client could send another query with an incremented IGMP hop limit, reaching deeper into the network, to expand the set of potential service providers. This scheme would leverage the existing IGMP protocol to enable the discovery and selection of services by network proximity, enable client discrimination of service providers (by their own criteria), enable a distribution of resource loads on service providers (by clients), and would keep discovery network traffic localized, when or where this is possible. Feel free to substitute clients for applications and service providers with servers, or clients and servers with peers, as needed. Thanks, Brett Patrick -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Laird Popkin Sent: Tuesday, February 10, 2009 12:22 PM 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
