Re: [p2pi] Information in an ALTO protocol

Stanislav Shalunov <shalunov@shlang.com> Fri, 12 September 2008 19:40 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 F34EF28C142; Fri, 12 Sep 2008 12:40:41 -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 1CFF53A6B9D for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 12:40:41 -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 tgPYQdonWkrF for <p2pi@core3.amsl.com>; Fri, 12 Sep 2008 12:40:40 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 10A5C3A6C71 for <p2pi@ietf.org>; Fri, 12 Sep 2008 12:40:40 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so876606rvf.49 for <p2pi@ietf.org>; Fri, 12 Sep 2008 12:40:43 -0700 (PDT)
Received: by 10.140.147.5 with SMTP id u5mr2875365rvd.166.1221248443086; Fri, 12 Sep 2008 12:40:43 -0700 (PDT)
Received: from Inbox ( [75.208.248.219]) by mx.google.com with ESMTPS id c20sm17092896rvf.3.2008.09.12.12.40.36 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Sep 2008 12:40:42 -0700 (PDT)
MIME-Version: 1.0
From: Stanislav Shalunov <shalunov@shlang.com>
Date: Fri, 12 Sep 2008 12:40:40 -0700
Importance: normal
X-Priority: 3
To: Laird Popkin <laird@pando.com>, Salman Abdul Baset <sa2086@columbia.edu>
Message-ID: <48cac5ba.14b48c0a.2f5d.ffffc26f@mx.google.com>
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

Let us put the privacy considertaions aside for a minute.

I'm actually not even sure how one would use uplink sizes if they were available, particularly only for some peers.

The underlying assumption of many messages seems to be that P2P clients will prefer to connect to higher-uplink peers.  While this would help you if you're the only one doing it, it would hurt everyone if done universally.

The only use I can think of right now that doesn't have obvious adverse consequences is to prefer peers with uplinks of about the same size as yours.  While this shouldn't reduce average download rate, I'm also not sure what purpose it would serve.  It would make the response to increases in uplink capacity more linear, but of course it's sublinear by design.

Can someone fill me in on how a P2P app would use provisioned uplink numbers?

Thanks, -- Stas

-----Original Message-----
From: "Laird Popkin" <laird@pando.com>
To: "Salman Abdul Baset" <sa2086@columbia.edu>
Cc: p2pi@ietf.org; "Richard Woundy" <Richard_Woundy@cable.comcast.com>
Sent: 9/11/08 1:28 PM
Subject: Re: [p2pi] Information in an ALTO protocol

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

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

- 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 perha
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi