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