Subject: Re: [alto] differences among applications

From: Laird Popkin <[email-masked]>
Date: Tue, 10 Feb 2009 12:22:10 -0500 (EST)

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-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Eric Burger" <[email-masked]>, [email-masked]
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-masked]> To: "Song Haibin"
> <[email-masked]> Cc: [email-masked] 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-masked] Skype:
>>> alexsonghw

---

From: "Patrick, Brett E Mr OCE/L-3 Communications" <[email-masked]>
Date: Tue, 10 Feb 2009 13:15:45 -0500

(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-masked] [mailto:[email-masked]] On Behalf Of
Laird Popkin
Sent: Tuesday, February 10, 2009 12:22 PM
To: [email-masked]
Cc: [email-masked]
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.

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Eric Burger" <[email-masked]>, [email-masked]
Sent: Tuesday, February 10, 2009 11:34:10 AM (GMT-0500) America/New_York
Subject: Re: [alto] differences among applications

Hi Laird,

Cheers,
R.

> ALTO server can take this into account when providing guidance, if the

> ISP (or whoever is running the ALTO server) cares to do so.
> 

> 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.
> 
>>> 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.
>> 
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 10 Feb 2009 12:45:06 -0800

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: "Robert Raszuk" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Eric Burger" <[email-masked]>, [email-masked]
Sent: Tuesday, February 10, 2009 11:34:10 AM (GMT-0500) America/New_York
Subject: Re: [alto] differences among applications

Hi Laird,

Cheers,
R.

---

From: Laird Popkin <[email-masked]>
Date: Tue, 10 Feb 2009 16:35:25 -0500 (EST)

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.

----- Original Message -----
From: "Saumitra Das" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, [email-masked]
Cc: [email-masked]
Sent: Tuesday, February 10, 2009 3:45:06 PM (GMT-0500) America/New_York
Subject: RE: [alto] differences among applications

-Saumitra

Qualcomm Research
Santa Clara, CA

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Eric Burger" <[email-masked]>, [email-masked]
Sent: Tuesday, February 10, 2009 11:34:10 AM (GMT-0500) America/New_York
Subject: Re: [alto] differences among applications

Hi Laird,

Cheers,
R.

---

From: Eric Burger <[email-masked]>
Date: Tue, 10 Feb 2009 20:28:47 -0500

And, for that matter, there is nothing to stop an ALTO oracle from  
getting its information from the peers.  The best of all worlds!

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.
>
> 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 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.
>

---

From: Song Haibin <[email-masked]>
Date: Wed, 11 Feb 2009 10:41:49 +0800

>From: [email-masked] [mailto:[email-masked]] 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

>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.
Laird
>Popkin
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.
>