Re: [p2pi] Information in an ALTO protocol

Stanislav Shalunov <shalunov@shlang.com> Mon, 15 September 2008 20:52 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 125E528C14D; Mon, 15 Sep 2008 13:52: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 29AE228C143 for <p2pi@core3.amsl.com>; Mon, 15 Sep 2008 13:52:55 -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 LqboMMBqVeQt for <p2pi@core3.amsl.com>; Mon, 15 Sep 2008 13:52:54 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 2AA4F28C14D for <p2pi@ietf.org>; Mon, 15 Sep 2008 13:52:54 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id k34so1559171wah.25 for <p2pi@ietf.org>; Mon, 15 Sep 2008 13:53:05 -0700 (PDT)
Received: by 10.114.159.17 with SMTP id h17mr52786wae.227.1221511985316; Mon, 15 Sep 2008 13:53:05 -0700 (PDT)
Received: from Inbox ( [75.211.51.251]) by mx.google.com with ESMTPS id d20sm19021339waa.37.2008.09.15.13.53.01 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Sep 2008 13:53:04 -0700 (PDT)
MIME-Version: 1.0
From: Stanislav Shalunov <shalunov@shlang.com>
Date: Mon, 15 Sep 2008 13:53:03 -0700
Importance: normal
X-Priority: 3
To: Laird Popkin <laird@pando.com>, Ye WANG <wangye.thu@gmail.com>
Message-ID: <48cecb30.1437720a.2626.0f2a@mx.google.com>
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="utf-8"
Content-Transfer-Encoding: base64
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

That's your own uplink capacity only.

I suspect even that would be hard to provide on DSL, where there is dynamic negotiation.

I'd expect measuring it once would be, while  deeply flawed, still give better results than asking...

Even better, of course, is to use real transfers as ongoing measurements, right?

-----Original Message-----
From: "Laird Popkin" <laird@pando.com>
To: "Ye WANG" <wangye.thu@gmail.com>
Cc: p2pi@ietf.org
Sent: 9/15/08 7:22 AM
Subject: Re: [p2pi] Information in an ALTO protocol

If a p2p application knows roughly what bandwidth the user is provisioned with, it can set reasonable defaults. 


For example, Azureus' configuration wizard asks users what kind of uplink speed they have (e.g. dial, 128K, 256K, ..., 1M) and uses different application level values (e.g. max upload speed, number of active transfers, number of active peer connections) appropriate for that kind of network connection. If they could automatically configure themselves rather than asking the user a rather intimidating (to a non-technical consumer) question, that would be better for the users and the network. 

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

----- Original Message ----- 
From: "Ye WANG" <wangye.thu@gmail.com> 
To: p2pi@ietf.org 
Sent: Monday, September 15, 2008 10:09:57 AM (GMT-0500) America/New_York 
Subject: Re: [p2pi] Information in an ALTO protocol 





On Fri, Sep 12, 2008 at 3:40 PM, Stanislav Shalunov < shalunov@shlang.com > wrote: 


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.  [Ye (Yale)] 
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.  How to efficiently use all upload capacity, especially those higher-uplink peers, is still an interesting problem. 




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. 

[Ye (Yale)] 

Analysis based on a fluid model of P2P file sharing system indicates that bandwidth matching can help improve average file download rate.  The bandwidth matching can be roughly described like: a peer with download capacity R downloads from the peer whose upload capacity R (=downloader download rate).  Thus, for file sharing applications, like Pando, BitTorrent, etc., the uplink/downlink bandwidth information can be useful in system optimization.  
In the recent P4P field test, we estimated these numbers before using them to compute peering selection weights.  Estimation based on measurement is dynamic and less accurate, while direct numbers from ALTO servers may be generally stati
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi