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 > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Song Haibin" <[email protected]> > To: "stefano previdi" <[email protected]>, "Saverio Mascolo" > <[email protected]> > Cc: [email protected] > Sent: Thursday, February 12, 2009 8:47:48 PM (GMT-0500) > America/New_York > Subject: Re: [alto] differences among applications > > > ______________________________________________________________________ > 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] > > 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 > _______________________________________________ > alto mailing list > [email protected] > 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 protected] _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
