Re: [p2pi] Information in an ALTO protocol
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Fri, 12 September 2008 15:31 UTC
Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845163A6B70; Fri, 12 Sep 2008 08:31:31 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C646D3A6B33 for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 08:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.174
X-Spam-Level:
X-Spam-Status: No, score=0.174 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VROABpQyKDz for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 08:31:28 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 13F6C3A6953 for <p2pi@ietf.org>; Fri, 12 Sep 2008 08:31:27 -0700 (PDT)
Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.13850404; Fri, 12 Sep 2008 11:31:05 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 11:31:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 12 Sep 2008 11:30:32 -0400
Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C4FA@PACDCEXCMB06.cable.comcast.com>
In-Reply-To: <C4F0399D.747E8%sprevidi@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] Information in an ALTO protocol
Thread-Index: AckUtrf69sJS6oCpEd2MNwAX8vOM8gAIjaowAABneW4AA+bWAA==
References: <74CCBBDF76102846AFA7B29F3A98D3F60107C4EE@PACDCEXCMB06.cable.comcast.com> <C4F0399D.747E8%sprevidi@cisco.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: stefano previdi <sprevidi@cisco.com>, Laird Popkin <laird@pando.com>, Salman Abdul Baset <sa2086@columbia.edu>
X-OriginalArrivalTime: 12 Sep 2008 15:31:05.0257 (UTC) FILETIME=[9216B990:01C914EC]
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Information in an ALTO protocol
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org
> well, I don't think there's anything there that needs do be standardized Sorry, I disagree. The protocol spec needs to make the semantics clear for a "user bandwidth" value. The spec could state that the value could be randomized / statistically balanced, so that such value manipulation could be anticipated by the ALTO client. Transparency is the key here. To be honest, I have my doubts whether randomization of the value will really help. The more randomization is used, the less effective this information will help the ALTO client. The less randomization is used, the more concerns I have about user privacy. I will step back from this debate and listen. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of stefano previdi Sent: Friday, September 12, 2008 9:22 AM To: Woundy, Richard; Laird Popkin; Salman Abdul Baset Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol > From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com> > >> Nothing prevents an ISP to configure his ALTO server in order answer > to > identical requests using some form of statistical-balancing preference. > > I would worry that the 'statistical balancing preference' could > alternatively viewed as 'ISP ALTO server is lying' or 'ISP ALTO server > prefers some applications over others'. I don't want to go there. well, I don't think there's anything there that needs do be standardized (or worked out in the context). Regarding the Alto-lies, it looks to me ALTO is a form of traffic engineering based on peer selection guidance. I don't see why a dynamic/variable algorithm (taking into consideration parameters such as time of day, current backbone load, ...) returning different results for the same query, would be considered as a "bad thing". But it also looks to me it's going to be something implementation specific. Being adopted/used or no will be the ISP choice. s. > > -- Rich > > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Friday, September 12, 2008 5:06 AM > To: Laird Popkin; Salman Abdul Baset > Cc: p2pi@ietf.org; Woundy, Richard > Subject: Re: [p2pi] Information in an ALTO protocol > >> From: Laird Popkin <laird@pando.com> >> >> (1) If an ISP configures their ALTO server to tell applications that > the >> users' uplink is less than it really is, I think that could have two > effects. >> For users inside the ISP, it would tend to suppress internal traffic > and cause >> peers to download from external peers, which is probably bad for the > ISP. And >> it might tend to cause peers from outside the ISP to shift traffic > elsewhere >> to some degree, which would reduce uplink utilization, which would be > an >> incentive to 'aim low'. How these two factors would balance out would > depend >> on the ISP's infrastructure. > > ... and on the ISP ALTO strategy. > > Nothing prevents an ISP to configure his ALTO server in order answer to > identical requests using some form of statistical-balancing preference. > > Multiple ISPs may want to cooperate by establishing ALTO policies among > their servers. > >> (2) I don't believe that the p2p network would have to decide that the > ISP's >> ALTO server was 'lying'. P2P networks all currently measure observed >> throughput between peers and use that to make decisions. If they add > ALTO >> provisioning information, I would expect that they would treat > observed >> throughput as being more true than the ALTO guidance. So without > having to >> make a decision about 'ALTO lying' the p2p network would tend to take >> advantage of good ALTO guidance (because ALTO guidance and p2p > performance >> optimization reinforce each other) and would tend to cancel out bad > ALTO >> guidance (because the p2p performance optimization would end up > overruling the >> ALTO guidance). > > I agree. What matters at the end of the day, is the measured > experience... > > s. > >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Salman Abdul Baset" <sa2086@columbia.edu> >> To: "Laird Popkin" <laird@pando.com> >> Cc: "Richard Woundy" <Richard_Woundy@cable.comcast.com>, p2pi@ietf.org >> Sent: Thursday, September 11, 2008 3:46:10 PM (GMT-0500) > America/New_York >> Subject: Re: [p2pi] Information in an ALTO protocol >> >> This raises at least two issues: >> >>> Playing devil's advocate, while ALTO doesn't provide a mechanism for > ISP A >>> to tell non-customers anything, but it is possible for the p2p > network >>> as a whole to make decisions based on information provided by ALTO. > For >>> example, if ISP A says that its users have bad uplink, and ISP B says >>> that its customers have great uplink, then the rest of the internet > will >>> tend to download more from ISP B than A. >> >> (1) Do ISPs have an incentive to lie to their customers that their > uplink >> is bad? >> >> This will be counter-balanced >>> in that if, in practice, ISP A has fine uplink, the p2p network will >>> figure that out and use those peers anyway, ignoring the misleading > ALTO >>> guidance, because observed behavior has (IMO) more 'weight' than ALTO >>> guidance. >> >> (2) Do P2P applications must determine if an ISP ALTO server is lying? >> >> Note, that misconfiguration can also be a cause of ALTO server > providing >> misleading information. >> >> -s >> >> >>> >>> ----- Original Message ----- >>> From: "Richard Woundy" <Richard_Woundy@cable.comcast.com> >>> To: "Reinaldo Penno" <rpenno@juniper.net>, "Laird Popkin" > <laird@pando.com> >>> Cc: p2pi@ietf.org >>> Sent: Thursday, September 11, 2008 2:52:06 PM (GMT-0500) > America/New_York >>> Subject: RE: [p2pi] Information in an ALTO protocol >>> >>>> I was wondering if he was assuming some kind inter-ALTO > communication. >>> >>> I guess I was. And perhaps Laird's points address my ISP traffic >>> management concerns -- I'm willing to concede. >>> >>> Still worried about user privacy, though. >>> >>> -- Rich >>> >>> -----Original Message----- >>> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf > Of >>> Reinaldo Penno >>> Sent: Thursday, September 11, 2008 2:31 PM >>> To: Laird Popkin; Woundy, Richard >>> Cc: p2pi@ietf.org >>> Subject: Re: [p2pi] Information in an ALTO protocol >>> >>> That was going to be my observation to Rich's point as well. I was >>> wondering >>> if he was assuming some kind inter-ALTO communication. But even if >>> existed >>> it would not be Internet wide. >>> >>> >>> On 9/11/08 11:26 AM, "Laird Popkin" <laird@pando.com> wrote: >>> >>>> The other issue is that ALTO is anticipated to be used by ISPs to >>> provide >>>> guidance to their own users. ALTO can't provide guidance to > customers >>> of other >>>> ISPs. So ISP A cannot tell the rest of the internet to pull data > from >>> ISP B >>>> but not ISP A. >>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >>> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
- [p2pi] Information in an ALTO protocol Enrico Marocco
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Vinay Aggarwal
- Re: [p2pi] Information in an ALTO protocol Lars Eggert
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol chsoft
- Re: [p2pi] Information in an ALTO protocol Vinay Aggarwal
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Sebastian Kiesel
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Fabio Hecht
- Re: [p2pi] Information in an ALTO protocol Song Haibin
- Re: [p2pi] Information in an ALTO protocol Vijay K. Gurbani
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Spencer Dawkins
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Reinaldo Penno
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Reinaldo Penno
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Salman Abdul Baset
- Re: [p2pi] Information in an ALTO protocol Griffiths, Chris
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Ye WANG
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Philip Levis
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Ye WANG
- Re: [p2pi] Information in an ALTO protocol The 8472
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Salman Abdul Baset