_____ From: [email protected] [mailto:[email protected]] On Behalf Of stefano previdi Sent: Thursday, February 12, 2009 11:42 PM To: Saverio Mascolo Cc: [email protected] Subject: Re: [alto] differences among applications
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. [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. 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. [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 protected]> 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 protected]> wrote: 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 protected]] Sent: Wednesday, February 11, 2009 3:54 PM To: DePriest, Greg (NBC Universal) Cc: [email protected] Subject: Re: [alto] differences among applications 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 protected]> 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 protected] [mailto:[email protected]] On Behalf Of Stanislav Shalunov Sent: Wednesday, February 11, 2009 2:51 PM To: Zoran Despotovic Cc: [email protected] Subject: Re: [alto] differences among applications 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 protected]> 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 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 -------------------------------------------------- _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto -- Stanislav Shalunov BitTorrent Inc [email protected] personal: http://shlang.com -- Stanislav Shalunov BitTorrent Inc [email protected] personal: http://shlang.com -- Stanislav Shalunov BitTorrent Inc [email protected] personal: http://shlang.com _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto -- 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 protected] <mailto:email%[email protected]> http://c3lab.poliba.it _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
