Subject: [alto] differences among applications

From: Zoran Despotovic <[email-masked]>
Date: Tue, 10 Feb 2009 11:14:46 +0100

Hi all,

I was wondering if and how IETF would address possible differences among 
relevant P2P applications in the sense that different applications may 
require totally different solutions. Was there any discussion on this 
before on the list?

Just as an example, different criteria to drive peer selection may work 
differently for give-to-get streaming and tit-for-tat BT. So how will 
IETF deal with this? Standardize different solutions for different 
applications? Standardize one solution for all? Pick the most critical 
(heaviest traffic) applications and standardize a solution for it?

It makes sense to clarify that at this early stage and, perhaps, first 
see if the solution should and can be application agnostic or not.

Best regards,
Zoran

-- 
Zoran Despotovic, Ph.D.
Senior Researcher

DOCOMO Communications Laboratories Europe GmbH
Landsbergerstrasse 312, 80687 Munich, Germany
Tel: +49-89-56824-205  Fax: +49-89-56824-300
http://www.docomoeurolabs.de/
 
Managing Directors (Geschaeftsfuehrer):
Dr. Toru Otsu, Dr. Narumi Umeda, Mr. Tsutomu Sakai
Amtsgericht Muenchen, HRB 132976
--------------------------------------------------

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 10 Feb 2009 12:16:28 +0100

> require totally different solutions. Was there any discussion on this 

Yes, there's been some discussion about how to deal with the fact that
different applications may have different requirements for peer
selection -- e.g. file-sharing would benefit most from connections to
peers with higher uplink bandwidth, while realtime communications
applications would probably want to chose media relays with the smallest
delay.

I remember someone suggested that a way to address it could be to simply
provide a means for the querying peer to specify what parameters it
would like to have optimized (delay, bandwidth...) and let the ALTO
server use such information in its processing. However, AFAIK, no
solution proposals at this time do anything like that.

-- 
Ciao,
Enrico

---

From: Song Haibin <[email-masked]>
Date: Tue, 10 Feb 2009 19:43:31 +0800

I think it is necessary to discuss whether we need to standardize different
peer selection algorithms according to different types of applications.

Best Regards,
Haibin
Email: [email-masked]
Skype: alexsonghw

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Enrico
>Marocco
>Sent: Tuesday, February 10, 2009 7:16 PM
>To: Zoran Despotovic
>Cc: [email-masked]
>Subject: Re: [alto] differences among applications
>
>Zoran Despotovic wrote:

---

From: stefano previdi <[email-masked]>
Date: Tue, 10 Feb 2009 13:25:10 +0100

> peer selection algorithms according to different types of  

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: Eric Burger <[email-masked]>
Date: Tue, 10 Feb 2009 08:52:45 -0500

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:

> 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

---

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Feb 2009 08:34:10 -0800

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
> 
>  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.
> 
>>> I think it is necessary to discuss whether we need to standardize
>>>  different peer selection algorithms according to different types
>>> of applications.
>>> Best Regards, Haibin Email: [email-masked] Skype:
>>> alexsonghw

---

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

I don't like the idea to standardize the peer selection algorithms for each
application either. 

But image that when ALTO server receives a request with a source peer and a
destination peer list for peer selection, it responds the ranking
information for each peer in the list. Here with different applications the
ranking result may be different. I don't know if ALTO server must implement
different peer selection algorithms internally for different applications,
so that it can rank the candidates list.

Or ALTO server does not need to understand the requirement of a specific
application, surely, it can responds to queries with parameters, e.g. the
ALTO server will not responds with the ranking info (generally a simple
ranking info will take a lot of considerations into account), but just the
topology information such as the routing hops from peer A to peer B is 5,
peer A to peer C is 4, the link quality from peer A to peer B is "good",
peer A to peer C is "fair", the economy cost..... And then with retrieval
many types of information what the application needs, the application makes
the choice.

So my general confusion here is whether the ALTO server needs to understand
the requirements of a specific application to do the peer selection.

Best Regards,
Haibin

>From: Eric Burger [mailto:[email-masked]]
>Sent: Tuesday, February 10, 2009 9:53 PM
>To: Song Haibin
>Cc: [email-masked]
>>> different

---

From: "Das, Saumitra" <[email-masked]>
Date: Wed, 11 Feb 2009 00:57:44 -0800

Some comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Song Haibin
Sent: Tuesday, February 10, 2009 6:22 PM
To: 'Eric Burger'
Cc: [email-masked]
Subject: Re: [alto] differences among applications

>>To enable this we need a way for an ALTO service to specify the metrics it can provide guidance on and a way for the application to select a metric of interest. Similar to P2PSIP, ALTO could have a alto service configuration document that provides such information. The p4p alto service could say that it supports the pDistance metric with a rating scale from 1 to X. Another alto service could use a different metric or multiple metrics. The application should have a way to specify the metric of interest. The ALTO service can then implement the peer selection which is just a ranking according to a metric it supports. It need not infer the application requirements.

>>I think the para above is a good direction. However, it is not clear how to tag the ranking info with good enough information to allow the application to make a good selection. The ALTO service potentially should be able to cull the list of not useful peers if some of them do not satisfy some constraint in the query and not have to return all annotated ranking info back to the client.

>>by requirement of a application if you mean the fact that an application can query for a metric of interest or specify a threshold (e.g. >128kbps), the ALTO server should likely be able to do this. It should not need to however infer the intent of the querying application i.e. giving a peer selection good for a p2p streaming application or good for a download service. The application should have to translate its needs to a standardized query supported by the ALTO server.

Best
Saumitra

Best Regards,
Haibin

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 11 Feb 2009 14:54:57 +0100

I don't like the idea of standardizing peer selection algorithms. Peer
selection must be able to consider various issues, which are not
restricted to topology and transport issues (e.g., fairness).  Also, app
designers must be able to modify the selection algorithm on short
notice. Therefore, I don't believe it is reasonable or even feasible to
offload the actual peer selection from the application to an ALTO
server. Furthermore, an ALTO server should not formulate responses
based on assumptions on how the peer selection algorithm in the app works,
hoping to influence it in a desired way.

I agree with Laird that the app should be able to tell ALTO which
attributes it cares about, and then ALTO gives advice while the
ultimate peer selection is performed in the app.

The ALTO protocol should be extensible, i.e., it should be possible to
add new attributes later. Nevertheless, I believe it would be useful if
we could come up with a list of initial (or basic) attributes.

Here are some candidates, which have already been discussed in the past.
Any additions or comments on the usefulness are most welcome:

- relative topological distance
  relative means that a larger numerical value means greater distance,
  but it is up to the ALTO service how to compute the values, and the
  app will not be informed about the nature of the information.
  One way *could* be counting AS hops, but when querying this parameter,
  the app must not assume that the numbers actually are AS hops.

- absolute topological distance, using a defined metric
  ... such as AS hops

- relative operator's preference
  higher numerical value means that the app should prefer this candidate
  peer over others with lower values (if no other reasons speak against
  it, such as probed througput). Again, as this is a relative measure,
  the ALTO service does not have to indicate how the values have been
  computed. Examples could be: cost for peering or transit traffic,
  traffic engineering inside the own network, and other policies.

- volume caps
  "you can transfer up to [amount of data] until [deadline] from/to 
  this (group of) node(s). excess traffic will be (throtteled|charged
  separately at [price unit] per [volume unit])"

- upper bound for achievable bandwidth (in replies) or
  lower bound for required bandwidth (in queries)

  an arbitrary upper bound for the bandwith from/to the candidate.
  this may be, but is not necessarily the provisioned access bandwith of
  the candidate peer.
  
  The application MUST be aware that with high probability, 
  the actually achievable data transfer rate is significantly less, as:
    - ALTO is not an admission control system
    - ALTO may not know the instantaneous congestion status of the network
    - ALTO may not know all link bandwidths, i.e., where the bottleneck
      really is, and there may be shared bottlenecks
    - ALTO may not know whether the candidate peer itself is overloaded
    - ALTO may not know whether the candidate peer throttles the
      bandwidth it devotes for the considered application
    - ALTO may not know whether the candidate peer will throttle the
      data it sends to us (e.g., because of tit-for-tat algorithm)

  That is, if the app really wants to know the effective bandwidth, it
  has to do measurements. Nevertheless, this parameter may be useful for
  excluding candidates right away. For example, if I was a FTTH customer
  and wanted to do P2P HQ multimedia streaming, I could ask ALTO to
  prune all known modem / GPRS users from a candidate list, because
  without doing measurements it is clear that they will not be able to
  exchange useful amounts of data with me.

- lower bound for achievable latency (or upper bound for acceptable latency)
  Same considerations as for the previous parameter apply here, too.
  Again, no guarantees, but only a means for quickly excluding hopeless
  candidates even before giving them a try and doing measurements.

- provisioned access bandwidth, e.g. of cable / DSL customers
  this has been proposed several times and questioned:
  problems with privacy, "premium" customers with high access bandwidth
  might attract so much traffic that their service is de-facto worse, ...

/* comments welcome */

Thanks,
Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 11 Feb 2009 10:19:46 -0800

Hello,

I mostly agree with your assessment of what an ALTO server is or is not.

Having said that, is this list of basic attributes mandatory? Can we clarify
basic vs. mandatory? I'm somewhat concerned with the complexity of the ALTO
server.

It would be good if an ISP could be up and running in a short timeframe once
the protocol is well-defined. Having to honor many attributes will make the
internal ALTO server implementation quite complex, with combinations,
relative priorities across many attributes, etc.

Thanks,

Reinaldo

On 2/11/09 5:54 AM, "Sebastian Kiesel" <[email-masked]>
wrote:

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

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 11 Feb 2009 11:50:54 -0800

As others pointed out, an ALTO protocol is not expected to make peer
selections for the apps.  On a high level, it's expected to provide
information about the network and about ISP routing preferences.
While peer selection preferences vary from application to application
substantially, the network itself is the same, and so the information about
it remains valid.

-- Stas

On Tue, Feb 10, 2009 at 2:14 AM, Zoran Despotovic <
[email-masked]> wrote:

> require totally different solutions. Was there any discussion on this before
> on the list?
>
> differently for give-to-get streaming and tit-for-tat BT. So how will IETF
> deal with this? Standardize different solutions for different applications?
> Standardize one solution for all? Pick the most critical (heaviest traffic)
> applications and standardize a solution for it?
>
> It makes sense to clarify that at this early stage and, perhaps, first see
> if the solution should and can be application agnostic or not.
>
> Best regards,
> Zoran
>
> --
> Zoran Despotovic, Ph.D.
> Senior Researcher
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 11 Feb 2009 15:11:01 -0500

Just to be sure:  You envision the app selecting peers for specific
pieces of content and peer selection will use network data of some type
in doing so?

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stanislav Shalunov
Sent: Wednesday, February 11, 2009 2:51 PM
To: Zoran Despotovic
Cc: [email-masked]
Subject: Re: [alto] differences among applications

While peer selection preferences vary from application to application
substantially, the network itself is the same, and so the information
about it remains valid.

-- Stas

On Tue, Feb 10, 2009 at 2:14 AM, Zoran Despotovic
<[email-masked]> wrote:

Hi all,

Best regards,
Zoran

-- 
Zoran Despotovic, Ph.D.
Senior Researcher

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 11 Feb 2009 12:54:01 -0800

That's, to me, the idea of ALTO.  The apps using information about ISP
routing preferences and the network to improve peer selection.

Note that this is a very broadly applicable technique: sure, BitTorrent and
other P2P apps are most obvious users to begin with, but any sort of app
that has a choice of network destinations can benefit.  Think along the
lines of CDNs, HTTP mirrors, or DNS servers choice, for example.

On Wed, Feb 11, 2009 at 12:11 PM, DePriest, Greg (NBC Universal) <
[email-masked]> wrote:

> pieces of content and peer selection will use network data of some type in
> doing so?
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Stanislav Shalunov
> *Sent:* Wednesday, February 11, 2009 2:51 PM
> *To:* Zoran Despotovic
> *Cc:* [email-masked]
> *Subject:* Re: [alto] differences among applications
>
>
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 11 Feb 2009 16:03:47 -0500

Makes perfect sense to me.  

Is it fair to say an ALTO server adds intelligence to the network?  

Or is it more accurate to say that ALTO enables more intelligent app
execution via the availability of network [and perhaps other]
information?  

From: Stanislav Shalunov [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2009 3:54 PM
To: DePriest, Greg (NBC Universal)
Cc: [email-masked]
Subject: Re: [alto] differences among applications

Note that this is a very broadly applicable technique: sure, BitTorrent
and other P2P apps are most obvious users to begin with, but any sort of
app that has a choice of network destinations can benefit.  Think along
the lines of CDNs, HTTP mirrors, or DNS servers choice, for example.

On Wed, Feb 11, 2009 at 12:11 PM, DePriest, Greg (NBC Universal)
<[email-masked]> wrote:

To: Zoran Despotovic
Cc: [email-masked]

-- Stas

Hi all,

Best regards,
Zoran

-- 
Zoran Despotovic, Ph.D.
Senior Researcher

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: stefano previdi <[email-masked]>
Date: Wed, 11 Feb 2009 22:06:19 +0100

On Feb 11, 2009, at 9:54 PM, Stanislav Shalunov wrote:

> That's, to me, the idea of ALTO.

to me too.

>  The apps using information about ISP routing preferences and the  
> network to improve peer selection.

and more generically: any selection process.

> Note that this is a very broadly applicable technique: sure,  
> BitTorrent and other P2P apps are most obvious users to begin with,  
> but any sort of app that has a choice of network destinations can  
> benefit.  Think along the lines of CDNs, HTTP mirrors, or DNS  
> servers choice, for example.

I fully subscribe to this.

s.

> pieces of content and peer selection will use network data of some  
> type in doing so?
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Stanislav Shalunov
> As others pointed out, an ALTO protocol is not expected to make  
> peer selections for the apps.  On a high level, it's expected to  
> provide information about the network and about ISP routing  
> preferences.
>
>
> While peer selection preferences vary from application to  
> application substantially, the network itself is the same, and so  
> the information about it remains valid.
>
>
> -- Stas
>
>
> I was wondering if and how IETF would address possible differences  
> among relevant P2P applications in the sense that different  
> applications may require totally different solutions. Was there any  
> discussion on this before on the list?
>
> Just as an example, different criteria to drive peer selection may  
> work differently for give-to-get streaming and tit-for-tat BT. So  
> how will IETF deal with this? Standardize different solutions for  
> different applications? Standardize one solution for all? Pick the  
> most critical (heaviest traffic) applications and standardize a  
> solution for it?
>
> It makes sense to clarify that at this early stage and, perhaps,  
> first see if the solution should and can be application agnostic or  
> not.
>
> Best regards,
> Zoran
>
> -- 
> Zoran Despotovic, Ph.D.
> Senior Researcher
>

---

From: stefano previdi <[email-masked]>
Date: Wed, 11 Feb 2009 22:10:16 +0100

> Is it fair to say an ALTO server adds intelligence to the network?
hmmm, it assumes that intelligence comes from the routing layer...  
looks great to me ;-)

> Or is it more accurate to say that ALTO enables more intelligent  
> app execution via the availability of network [and perhaps other]  
> information?

yes, this is maybe more accurate... and I like the "perhaps other"...

s.

> That's, to me, the idea of ALTO.  The apps using information about  
> ISP routing preferences and the network to improve peer selection.
>

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 11 Feb 2009 13:16:54 -0800

We haven't discussed anything about ALTO influencing actual underlay routing
or anything of the sort.
So I suppose it makes apps smarter by giving them more knowledge about the
network and the routing preferences.

On Wed, Feb 11, 2009 at 1:03 PM, DePriest, Greg (NBC Universal) <
[email-masked]> wrote:

> execution via the availability of network [and perhaps other] information?
>
>
> *From:* Stanislav Shalunov [mailto:[email-masked]]
> *Sent:* Wednesday, February 11, 2009 3:54 PM
> *To:* DePriest, Greg (NBC Universal)
>
> *Cc:* [email-masked]
> Just to be sure:  You envision the app selecting peers for specific pieces
> of content and peer selection will use network data of some type in doing
> so?
>
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Zoran Despotovic <[email-masked]>
Date: Thu, 12 Feb 2009 09:38:36 +0100

> information about the network and about ISP routing preferences.
Makes sense. In fact, I guess that is the only correct view.
> substantially, the network itself is the same, and so the information 
Same as above :). The point is to define precisely what the network 
should say about itself. Pure locality information may not be enough for 
streaming apps, or at least not as good as for BT. Or, we need to prove 
or disprove that.

Best,
Zoran

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 12 Feb 2009 10:32:50 +0100

Hi,

just to clarify about the "list of initial (or basic) attributes": 
My proposal is NOT to mandate that every ALTO server or client must
support all of them! My idea is that the members of this WG should
compile a list of attributes, each with a well-defined semantic and at
least some support (i.e., some people should say that they would like to
consider this type of information in their peer selection / scheduling /
whatever algorithms). This is important to determine how much
flexibility in the ALTO protocol we actually need, and therefore,
comments on this initial list of attributes or additions are most
welcome. People implementing ALTO would be free to implement only a
subset of this list, or adding their own attributes.

thanks,
  Sebastian

---

From: Saverio Mascolo <[email-masked]>
Date: Thu, 12 Feb 2009 16:32:27 +0100

ALTO aims at providing  informations on network status, i.e. feedback,  so
that applications can make smarter decision.

A potential warning here comes from the fact that the applications  close
the loop and this maybe destabilizing.

Thus,   standardiation should also involve how to use  ALTO informations to
pursue  objectives such as load balancing routing etc. In other terms
standardization should involve information and how to use it.

2009/2/11 Stanislav Shalunov <[email-masked]>

> We haven't discussed anything about ALTO influencing actual underlay
> routing or anything of the sort.
>> and other P2P apps are most obvious users to begin with, but any sort of app
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Stanislav Shalunov

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://c3lab.poliba.it

---

From: stefano previdi <[email-masked]>
Date: Thu, 12 Feb 2009 16:41:58 +0100

On Feb 12, 2009, at 4:32 PM, Saverio Mascolo wrote:

> ALTO aims at providing  informations on network status, i.e.  
> feedback,  so that applications can make smarter decision.

well, ALTO is delivering a ranking/preference system and not any  
information about network status.

Now, network status _may_ be used in order to derive/compute a given  
preference. This is in hands of the ALTO provider and not supposed to  
be standardized in any form.

> A potential warning here comes from the fact that the applications   
> close the loop and this maybe destabilizing.
>
> Thus,   standardiation should also involve how to use  ALTO  
> informations to pursue  objectives such as load balancing routing  
> etc. In other terms standardization should involve information and  
> how to use it.

I don't think I agree here.

Standardizing "use of ALTO information" assumes you enforce a  
specific behavior. It will be unpractical and (IMHO) limited in its  
effectiveness.

s.

> We haven't discussed anything about ALTO influencing actual  
> underlay routing or anything of the sort.
>
> So I suppose it makes apps smarter by giving them more knowledge  
> about the network and the routing preferences.
>
>
> On Wed, Feb 11, 2009 at 1:03 PM, DePriest, Greg (NBC Universal)  
> email:[email-masked]

---

From: Saverio Mascolo <[email-masked]>
Date: Thu, 12 Feb 2009 18:44:28 +0100

On Thu, Feb 12, 2009 at 4:41 PM, stefano previdi <[email-masked]> wrote:

> preference. This is in hands of the ALTO provider and not supposed to be
> standardized in any form.
>

the use of the ranking/preference as a base for any decision will close the
loop. this may  trigger closed loop dynamics.  TCP is an example of closed
loop dynamics, even though in a much poor information context.

-s

> Standardizing "use of ALTO information" assumes you enforce a specific
> behavior. It will be unpractical and (IMHO) limited in its effectiveness.
>
> s.
>
>
>
>
>
>

---

From: Song Haibin <[email-masked]>
Date: Fri, 13 Feb 2009 09:47:48 +0800

_____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
stefano previdi
Sent: Thursday, February 12, 2009 11:42 PM
To: Saverio Mascolo
Cc: [email-masked]
Subject: Re: [alto] differences among applications

well, ALTO is delivering a ranking/preference system and not any information
about network status.

[Song Haibin] Then what information should be in the ranking form and what
information should not be?

A potential warning here comes from the fact that the applications close the
loop and this maybe destabilizing.

 

[Song Haibin] Um. for designing each parameter of ALTO information, I think
the motivation itself is the guidance on how to use this kind of ALTO
information.

s.

  _____  

Cc: [email-masked]

Note that this is a very broadly applicable technique: sure, BitTorrent and
other P2P apps are most obvious users to begin with, but any sort of app
that has a choice of network destinations can benefit. Think along the lines
of CDNs, HTTP mirrors, or DNS servers choice, for example.

Just to be sure: You envision the app selecting peers for specific pieces of
content and peer selection will use network data of some type in doing so?

  _____  

To: Zoran Despotovic
Cc: [email-masked]

-- Stas

Hi all,

Best regards,
Zoran

-- 
Zoran Despotovic, Ph.D.
Senior Researcher

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari 
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <mailto:[email-masked]> 

http://c3lab.poliba.it

alto mailing list

[email-masked]

---

From: Laird Popkin <[email-masked]>
Date: Thu, 12 Feb 2009 21:02:23 -0500 (EST)

There shouldn't be much risk of ALTO forming a "feedback loop" because ALTO is intended only to communicate relatively static information, and specifically is not intended to communicate real-time status information, which is a transport issue. 

----- Original Message ----- 
From: "Song Haibin" <[email-masked]> 
To: "stefano previdi" <[email-masked]>, "Saverio Mascolo" <[email-masked]> 
Cc: [email-masked] 
Sent: Thursday, February 12, 2009 8:47:48 PM (GMT-0500) America/New_York 
Subject: Re: [alto] differences among applications 

From: [email-masked] [mailto:[email-masked]] On Behalf Of stefano previdi 
Sent: Thursday, February 12, 2009 11:42 PM 
To: Saverio Mascolo 
Cc: [email-masked] 
Subject: Re: [alto] differences among applications 

ALTO aims at providing informations on network status, i.e. feedback, so that applications can make smarter decision. 

well, ALTO is delivering a ranking/preference system and not any information about network status. 

Now, network status _may_ be used in order to derive/compute a given preference. This is in hands of the ALTO provider and not supposed to be standardized in any form. 

[Song Haibin] Then what information should be in the ranking form and what information should not be? 

A potential warning here comes from the fact that the applications close the loop and this maybe destabilizing. 

Thus, standardiation should also involve how to use ALTO informations to pursue objectives such as load balancing routing etc. In other terms standardization should involve information and how to use it. 

  

Standardizing "use of ALTO information" assumes you enforce a specific behavior. It will be unpractical and (IMHO) limited in its effectiveness. 

[Song Haibin] Um… for designing each parameter of ALTO information, I think the motivation itself is the guidance on how to use this kind of ALTO information. 

s . 

2009/2/11 Stanislav Shalunov < [email-masked] > 

We haven't discussed anything about ALTO influencing actual underlay routing or anything of the sort. 

So I suppose it makes apps smarter by giving them more knowledge about the network and the routing preferences. 

On Wed, Feb 11, 2009 at 1:03 PM, DePriest, Greg (NBC Universal) < [email-masked] > wrote: 

  

  

Or is it more accurate to say that ALTO enables more intelligent app execution via the availability of network [and perhaps other] information? 

From: Stanislav Shalunov [mailto: [email-masked] ] 
Sent: Wednesday, February 11, 2009 3:54 PM 
To: DePriest, Greg (NBC Universal) 

Cc: [email-masked] 

That's, to me, the idea of ALTO. The apps using information about ISP routing preferences and the network to improve peer selection. 

Note that this is a very broadly applicable technique: sure, BitTorrent and other P2P apps are most obvious users to begin with, but any sort of app that has a choice of network destinations can benefit. Think along the lines of CDNs, HTTP mirrors, or DNS servers choice, for example. 

On Wed, Feb 11, 2009 at 12:11 PM, DePriest, Greg (NBC Universal) < [email-masked] > wrote: 

Just to be sure: You envision the app selecting peers for specific pieces of content and peer selection will use network data of some type in doing so? 

From: [email-masked] [mailto: [email-masked] ] On Behalf Of Stanislav Shalunov 
Sent: Wednesday, February 11, 2009 2:51 PM 

To: Zoran Despotovic 
Cc: [email-masked] 

As others pointed out, an ALTO protocol is not expected to make peer selections for the apps. On a high level, it's expected to provide information about the network and about ISP routing preferences. 

While peer selection preferences vary from application to application substantially, the network itself is the same, and so the information about it remains valid. 

-- Stas 

On Tue, Feb 10, 2009 at 2:14 AM, Zoran Despotovic < [email-masked] > wrote: 

Hi all, 

I was wondering if and how IETF would address possible differences among relevant P2P applications in the sense that different applications may require totally different solutions. Was there any discussion on this before on the list? 

Just as an example, different criteria to drive peer selection may work differently for give-to-get streaming and tit-for-tat BT. So how will IETF deal with this? Standardize different solutions for different applications? Standardize one solution for all? Pick the most critical (heaviest traffic) applications and standardize a solution for it? 

It makes sense to clarify that at this early stage and, perhaps, first see if the solution should and can be application agnostic or not. 

Best regards, 
Zoran 

-- 
Zoran Despotovic, Ph.D. 
Senior Researcher 

-- 
Stanislav Shalunov 
BitTorrent Inc 
[email-masked] 

-- 
Stanislav Shalunov 
BitTorrent Inc 
[email-masked] 

-- 
Stanislav Shalunov 
BitTorrent Inc 
[email-masked] 

http://c3lab.poliba.it 

alto mailing list 

[email-masked] 

_______________________________________________ alto mailing list [email-masked] https://www.ietf.org/mailman/listinfo/alto

---

From: "Kellerer, Wolfgang" <[email-masked]>
Date: Fri, 13 Feb 2009 09:33:22 +0100

Dear All,

I think the application class discussion we had is very important for a
useful ALTO service. This poses two requirements: the ALTO server to
understand application requirements and the ALTO client to understand
the ALTO response.

Let me try to summarize:

The ALTO service is not for application specific peer selection or
implements multiple selection algorithms. 
However, if both ALTO application and ALTO service provider should
benefit - otherwise it will not be used - it is important that both
understand each other while keeping the protocol simple:

- the ALTO server has to understand simple application requirements (as
discussed before), e.g., application class; I would propose to be more
abstract here

- the ALTO client (application) has to understand the response from the
ALTO server (has not fully been discussed before, see Zoran's email):
what is the basis for the ALTO information - as it is unlikely that the
ALTO server will reveal all the network internals, some abstract
notation is needed that can be easily understood by the client

Not all of the information is mandatory, but we might consider a
mandatory and an optional set.

Do we have this in the current requirements? I think this is very
important.

Regards,

Wolfgang

------------------------------------------
Dr. Wolfgang Kellerer
Senior Manager
Ubiquitous Networking Research
DOCOMO Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany

Tel. +49-89-56824-222
Fax. +49-89-56824-300
E-mail: [email-masked]
http://www.docomolab-euro.com

Managing Directors (Geschaeftsfuehrer):
Dr. Toru Otsu, Dr. Narumi Umeda, Tsutomo Sakai
Amtsgericht Muenchen, HRB 132976
------------------------------------------
private URL: http://www.wolfgangkellerer.de

> Zoran Despotovic
> Sent: Donnerstag, 12. Februar 2009 09:39
> To: Stanislav Shalunov
> Cc: [email-masked]
application

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Feb 2009 09:04:06 -0600

Kellerer, Wolfgang wrote:
 > Dear All,
 >
 > I think the application class discussion we had is very important for
 > a useful ALTO service. This poses two requirements: the ALTO server to

Wolfgang: Thanks for the summary -- that helps a lot.

This is a good discussion to have, please keep it going.  One

 > Do we have this in the current requirements? I think this is very

When we were working on the charter definition, we were (luckily)
prescient enough to recognize that different applications will
have different requirements.  To that extent, I do want to
point out the following from our charter:

   - A document defining core request and response formats
   and semantics to communicate network preferences to
   applications.  Since ALTO services may be run by entities
   with different level of knowledge about the underlying
   network, such preferences may have different representations.
   Initially the WG will consider: IP ranges to prefer and
   to avoid, ranked lists of the peers requested by the client,
   information about topological proximity and approximate
   geographic locations.  Other usages will be considered
   as charter additions once the work for the initial services
   has been completed.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Fabio Hecht <[email-masked]>
Date: Tue, 17 Feb 2009 14:10:01 +0100

Dear Laird, all,

On Thu, 2009-02-12 at 21:02 -0500, Laird Popkin wrote:
> There shouldn't be much risk of ALTO forming a "feedback loop" because
> ALTO is intended only to communicate relatively static information,
> and specifically is not intended to communicate real-time status
> information, which is a transport issue.

The problem statement reads:

"Bottlenecks, limited
   throughput, and intermittent links often has much more influence on
   the peer's perceived quality of service and network utilization than
   round-trip time."

I don't think this refers to static information.

Regards Fabio

> ______________________________________________________________________
> From:[email-masked] [mailto:[email-masked]] On Behalf Of
> stefano previdi
> ALTO aims at providing informations on network status, i.e. feedback,
> so that applications can make smarter decision. 
> 
>  
> 
> 
> Thus, standardiation should also involve how to use ALTO informations
> to pursue objectives such as load balancing routing etc. In other
> terms standardization should involve information and how to use it.
> 
>  
> 
> 
> [Song Haibin] Um… for designing each parameter of ALTO information, I
> think the motivation itself is the guidance on how to use this kind of
> ALTO information.
> 
>  
> 
>  
> 
>  
> 
> 
> s.
> 
> 
>  
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> From:Stanislav Shalunov [mailto:[email-masked]] 
> benefit. Think along the lines of CDNs, HTTP mirrors, or DNS servers
> choice, for example.
> 
> 
>  
> 
> 
> ______________________________________________________________________
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stanislav Shalunov
> work differently for give-to-get streaming and tit-for-tat BT. So how
> will IETF deal with this? Standardize different solutions for
> _______________________________________________ alto mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/alto
-- 
Fabio Hecht

University of Zurich - Department of Informatics (IfI)
Binzmühlestrasse 14 CH-8050 Zürich, Switzerland
Ph.: +41 44 6357129 / 6350892  Fax: +41 44 6356809
VoIP sip:[email-masked]

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 17 Feb 2009 14:30:34 +0100

> I don't think this refers to static information.

That sentence in its original context was actually supposed to make the
point that knowledge of capacity and topology of the underlying links
(i.e. static information) is more useful than RTT measurements (i.e.
dynamic info) for peer selection in file-sharing applications.

Besides, the problem statement is still an individual draft and does not
reflect the consensus of the WG; the only document agreed so far is the
charter, which clearly states:

  In any case, this WG will not propose standards on how congestion is
  signaled, remediated, or avoided, and will not deal with information
  representing instantaneous network state.

-- 
Ciao,
Enrico

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 23 Feb 2009 10:51:38 -0500

>    as charter additions once the work for the initial services

How broad is the understanding of  "information about 
topological proximity and approximate geographic locations."?  
Latency might be included, but bandwidth doesn't sound like it's
a characteristic of topological proximity or geography.  

Maybe an ALTO server must understand and be able to respond 
with {whatever data set we decide}, but whether any given 
field is used is a local policy decision: you can always ask me for 
topological data, but I can always answer "None of your 
business."  That also promotes rapid deployment--an ISP can
roll quickly even if it only has one datum.

If I understand where we are now, there are two possible query 
sets from a client:
Q:  "Here's a list of potential peers, please rank them."  
A:  p1, p2, p3, ... pn

Q:  "Send me a list of network prefixes with relative 
preferredness."
A:  300,000 entries from routing table with forwarding information 
abstracted.

In the first instance, as long as the number of peers is limited, I can
imagine the client asking the server to customize the response based
on client (application) preferences, e.g., "Please weight packet loss 
as an important consideration."  Of course, the server operator can
set weights per policy or ignore the requested ranking, but that may
be a feature of a specific implementation and not explicit in the 
protocol definition.

In the second instance, there's a potential scaling problem,
depending on the level of data provided.  The server will not 
be able to sort 300k entries according to the client's relative
priorities.  It also seems to me that much of the data useful for 
decisions is only available for individual potential peers:

					Function
Attibute		Rank pot. peers	Pref'd prefixes
latency,		yes				yes
cost			yes				yes
bandwidth, 		yes				no
packet loss, 		yes				no
reliability, 		yes				no
time sensitivity, 	yes				no
burstiness, 		yes				no

Even latency, though, would be relative to the ALTO server, not 
the ALTO client.  

Responding to multiple subthreads in one message, but I thought
it would be more efficient this way.

Lee

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.