Re: [p2pi] Information in an ALTO protocol

stefano previdi <sprevidi@cisco.com> Fri, 12 September 2008 09:06 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 F250D3A688A; Fri, 12 Sep 2008 02:06:46 -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 32B8C3A67EE for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 02:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Gd03IWIEE9Jn for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 02:06:45 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A9B6E3A6BE1 for <p2pi@ietf.org>; Fri, 12 Sep 2008 02:06:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m8C969s29386; Fri, 12 Sep 2008 11:06:10 +0200 (CEST)
Received: from [144.254.189.64] (dhcp-rom2-144-254-189-64.cisco.com [144.254.189.64]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m8C95lA28408; Fri, 12 Sep 2008 11:05:51 +0200 (CEST)
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Fri, 12 Sep 2008 11:05:36 +0200
From: stefano previdi <sprevidi@cisco.com>
To: Laird Popkin <laird@pando.com>, Salman Abdul Baset <sa2086@columbia.edu>
Message-ID: <C4EFFD80.7478A%sprevidi@cisco.com>
Thread-Topic: [p2pi] Information in an ALTO protocol
Thread-Index: AckUtrf69sJS6oCpEd2MNwAX8vOM8g==
In-Reply-To: <284285064.257961221164880361.JavaMail.root@dkny.pando.com>
Mime-version: 1.0
Cc: Richard Woundy <Richard_Woundy@cable.comcast.com>, 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

> 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