Re: [p2pi] Information in an ALTO protocol

Laird Popkin <laird@pando.com> Thu, 18 September 2008 14:38 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 7FE733A6916; Thu, 18 Sep 2008 07:38:22 -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 7095A3A6916 for <p2pi@core3.amsl.com>; Thu, 18 Sep 2008 07:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.148
X-Spam-Level:
X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
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 U21w4gzgd9lZ for <p2pi@core3.amsl.com>; Thu, 18 Sep 2008 07:38:16 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 12BBD3A6774 for <p2pi@ietf.org>; Thu, 18 Sep 2008 07:38:15 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5803AE10A9E; Thu, 18 Sep 2008 10:38:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHjR8Tf3vXwv; Thu, 18 Sep 2008 10:38:11 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 7DA46E10AE7; Thu, 18 Sep 2008 10:38:11 -0400 (EDT)
Date: Thu, 18 Sep 2008 10:38:11 -0400
From: Laird Popkin <laird@pando.com>
To: Stanislav Shalunov <shalunov@shlang.com>
Message-ID: <1075705079.276231221748691472.JavaMail.root@dkny.pando.com>
In-Reply-To: <550647734.275901221746432865.JavaMail.root@dkny.pando.com>
MIME-Version: 1.0
X-Originating-IP: [10.10.20.75]
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: multipart/mixed; boundary="===============0533076858=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org


Keep in mind that ALTO only guides which peers you connect to first, not which peers (out of those) that you choose to exchange data with, or even which peers you eventually connect to (i.e. ALTO just adds to the existing peer discovery strategies that p2p networks already utilize, such as peer exchange, DHT's, and random peer connections). So while ALTO might help you connect to faster peers first, it can't prevent you from connecting to all other peers over time. 



One way to benefit from knowing user link capacities is to do bandwidth matching. So rather than simply telling all peers to connect to the fastest peers, it might make more sense to tell the fastest peers to connect to each other first, creating high speed seeds who can then serve to slower peers. This is 'better than random' because there's more value (to the network) in sending data to faster peers who can then be better seeds, even if it is 'unfair' to the slower peers at some level, because ultimately all users benefit from more, faster seeds. 



So what ALTO might allow (if it exposes peer uplink capacities, and p2p networks use that to preferentially assign peers) is that it would shift demand away from slow peers towards faster peers. But if the fastest peers are already utilizing 100% of their uplink, the traffic will shift to the slower peers, and so on, until eventually (if there's sufficient demand) all peers are serving 100% of their uplink. 



Think of it this way: at a point in time a p2p swarm consists of peers with a range of uplink capacities, and a particular level of demand for data. Early in a swarm's life, demand exceeds supply (i.e. there are few seeds and many downloaders). Later in a swarm's life (i.e. once the swarm is well seeded) supply exceeds demand. 



When the demand exceeds supply, then you always want to use all available uplink from all seeds, so there's no selection, but it doesn't particularly hurt to try connecting to fastest seeds first (assuming that the negotiation process is lightweight,which it is for BitTorrent, for example). 



If the demand does not exceed supply, then you want to pick the fastest seeds first because they'll deliver the data faster. This is not only good for the end users, but it also creates more seeds faster, making the swarm more healthy. If ALTO exposes user link capacities, that helps select faster seeds. 



In addition, ISPs might want p2p networks to prefer pulling data from users with faster uplink speeds, because it reduces the demand on the users with slower uplink speeds. For example, if an ISP has a mixture of capacities (e.g. DSL and FTTH, or DOCSIS 1/2/3), it's probably good for the p2p networks to consume the FTTH and DOCSIS 3 uplink first, because there's more capacity available there. That is, users and ISPs might be happier if a p2p network pulls 5 Mbps from 50% of one FTTH customer rather than saturating 10 DSL customers. 


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

----- Original Message ----- 
From: "Stanislav Shalunov" <shalunov@shlang.com> 
To: "Ye WANG" <wangye.thu@gmail.com> 
Cc: p2pi@ietf.org 
Sent: Monday, September 15, 2008 9:02:38 PM (GMT-0500) America/New_York 
Subject: Re: [p2pi] Information in an ALTO protocol 



On Sep 15, 2008, at 7:09 AM, Ye WANG wrote: 



We have seen many studies on video streaming applications that prefer higher-uplink-bandwidth peers.  I certainly agree with you that the system may somehow get 'blocked' if all clients naively select the highest-uplink peer to be parents.  


Better yet, if this is taken literally, the system turns client/server: the peers with absolute highest uplinks form the server bank and nobody else uploads anything.  This, of course, dramatically reduces swarm efficiency and thus download rates. 


If done as a preference, the effect is not as extreme, but still a move in the same counterproductive direction. 







Analysis based on a fluid model of P2P file sharing system indicates that bandwidth matching can help improve average file download rate. 


I'd like to understand this better.  I understand the effect with more linear response -- bigger uplink now means proportionally higher uplinks of your peers, which means higher download rate, linearly.  I don't yet see why capacity matching will improve average rate. 


Anyway -- the sublinear response is consciously designed and desirable -- with it, high-capacity peers still have an incentive to contribute, while a majority of peers see improved outcomes.  Think of a log(rate) utility function -- 50% better outcomes for 10 typical peers are worth 30% worse outcome for 1 unusually well-provisioned peer. 


Making the response more linear will improve the outcomes of a few very well-off peers at the expense of a large number of typical ones.  I do not yet see why it is desirable. 


-- 
Stanislav Shalunov 

Hacking Startups

_______________________________________________ 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