Re: [p2pi] Information in an ALTO protocol

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Tue, 12 August 2008 16:26 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 2164D3A6B69; Tue, 12 Aug 2008 09:26:57 -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 A82283A69C2 for <p2pi@core3.amsl.com>; Tue, 12 Aug 2008 09:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.313
X-Spam-Level:
X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, 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 NAPQfeQVXBwu for <p2pi@core3.amsl.com>; Tue, 12 Aug 2008 09:26:55 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5A34A3A6BA0 for <p2pi@ietf.org>; Tue, 12 Aug 2008 09:26:42 -0700 (PDT)
Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.10874025; Tue, 12 Aug 2008 12:26:17 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 12:26:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 12 Aug 2008 12:26:14 -0400
Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C335@PACDCEXCMB06.cable.comcast.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] Information in an ALTO protocol
Thread-Index: Acj8ij9hFuOMnZglSKSCHIKepvxB0gADeR2e
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: laird@pando.com, nweaver@ICSI.Berkeley.EDU
X-OriginalArrivalTime: 12 Aug 2008 16:26:15.0892 (UTC) FILETIME=[24934940:01C8FC98]
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

I don't disagree that you can measure a user's throughput, and in fact this is necessary for certain applications that negotiate codecs, eg iChat. But with speedtest servers and application-based measurement, there is an explicit or implicit opt-in by the user.

I suppose the ISP's ALTO service could also enable opt-in for the customer's provisioned speed to be reported, but I wonder how many customers would be incented to do this, and would that re-enforce any traffic concentration effects that I mentioned before (because few users opt in).

I suspect that knowing the link speed doesn't really enable the application to avoid testing for the actual available bandwidth, given that other applications may be consuming bandwidth.

-- Rich


----- Original Message -----
From: Laird Popkin <laird@pando.com>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>; Woundy, Richard; p2pi@ietf.org <p2pi@ietf.org>
Sent: Tue Aug 12 10:45:32 2008
Subject: Re: [p2pi] Information in an ALTO protocol

Many p2p networks already do this sort of thing, and I can't think of any way that the ISP could prevent it - any p2p app can measure throughput and report it. For example, see http://www.speedtest.net/global.php. Of course, this is only based on users that installed the agent, which may not be representative, and doesn't different between classes of users (since the agent can't tell whether they're on a DOCSIS 1/2/3 cable modem, etc.).

The advantage of getting link capacity info from the ISP rather than by measurement is that it's a bit faster and more consistent, and saves a little bandwidth by not doing the test.

The other alternative is to use commercial IP mapping databases (e.g. MaxMind's netspeed database), which is fast and cheap, but these databases not as accurate or precise as an ISP could be. For example, MaxMind differentiates between dial, broadband and corporate, but not between classes of broadband.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
To: "Laird Popkin" <laird@pando.com>
Cc: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>, "Richard Woundy" <Richard_Woundy@cable.comcast.com>, p2pi@ietf.org
Sent: Tuesday, August 12, 2008 10:28:03 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Information in an ALTO protocol


On Aug 12, 2008, at 7:12 AM, Laird Popkin wrote:

> Interesting points. I'm not paranoid enough. :-)

No, you're not.  Its not paranoia when they are out to get you.

> How about if this is exposed only to the ISP's customers?

My company-X P2P business model includes an agent I control on the  
user's computer, no?

So if its valuable, Company-X can use company-X's customers to mine  
the data.  This would especially be useful because you could do a  
direct increase in performance by feeding back the data to the  
tracking infrastructure.


_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi