Re: [p2pi] Information in an ALTO protocol

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Fri, 12 September 2008 13:14 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 E8BF03A6908; Fri, 12 Sep 2008 06:14:19 -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 8B1D33A65A5 for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 06:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level:
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=0.743, 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 XaD1yp4-2CbG for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 06:14:17 -0700 (PDT)
Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 2F4303A6ACF for <p2pi@ietf.org>; Fri, 12 Sep 2008 06:14:13 -0700 (PDT)
Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.50569658; Fri, 12 Sep 2008 09:13:45 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 09:13:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 12 Sep 2008 09:13:43 -0400
Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C4EE@PACDCEXCMB06.cable.comcast.com>
In-Reply-To: <C4EFFD80.7478A%sprevidi@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] Information in an ALTO protocol
Thread-Index: AckUtrf69sJS6oCpEd2MNwAX8vOM8gAIjaow
References: <284285064.257961221164880361.JavaMail.root@dkny.pando.com> <C4EFFD80.7478A%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 13:13:44.0458 (UTC) FILETIME=[623096A0:01C914D9]
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

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

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