Re: [p2pi] Information in an ALTO protocol

"Ye WANG" <wangye.thu@gmail.com> Tue, 16 September 2008 04:39 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 2FE743A69D7; Mon, 15 Sep 2008 21:39:28 -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 0FB243A6976 for <p2pi@core3.amsl.com>; Mon, 15 Sep 2008 21:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6]
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 j9v6oTAWgwGw for <p2pi@core3.amsl.com>; Mon, 15 Sep 2008 21:39:25 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id CFEB93A69F8 for <p2pi@ietf.org>; Mon, 15 Sep 2008 21:39:25 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2294568rvf.49 for <p2pi@ietf.org>; Mon, 15 Sep 2008 21:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=hMOVKjbJwl1WWtifAUyQ/BXIUw9AYeb+gGiL40pgLuA=; b=WRlcv7kRiB7jxHg8j1yuDo6CkyIcwFE3sCFTxobH81+OEAUbPHoXBrQ2tCz/JnIi3J 5i2w2FVulYh46A2TiT9n6CDog2eV4+MclE+W+RtoVMq+bSnjkNQBXPZt01fxNe2XffU1 SMk9qaptQJguYPtZjmOKnO1K90MgVURgh+aNY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=DJofci+RUhfdO0NDr4bESCfH3nTeeroAdncZtggRd5qlYUX5MPwA+ONnLvPovUG1IG QoSdFnkc16HzYtYQk7XvbL4Z+8Y+wBvrCcJP2m+FAjA1jvTGYabCyzezxQajBHuo6oEr YCLuJxfGjwz9YoZfo5oCK9WK8XR+QYtW+A5Jc=
Received: by 10.141.113.6 with SMTP id q6mr5372175rvm.36.1221539975844; Mon, 15 Sep 2008 21:39:35 -0700 (PDT)
Received: by 10.140.203.16 with HTTP; Mon, 15 Sep 2008 21:39:35 -0700 (PDT)
Message-ID: <2574b1d30809152139k14fd1aa3gb6ef578fabf90349@mail.gmail.com>
Date: Tue, 16 Sep 2008 00:39:35 -0400
From: Ye WANG <wangye.thu@gmail.com>
To: Stanislav Shalunov <shalunov@shlang.com>, p2pi@ietf.org
In-Reply-To: <3DABE53F-A150-4720-8139-D05BD57AE613@shlang.com>
MIME-Version: 1.0
References: <48cac5ba.14b48c0a.2f5d.ffffc26f@mx.google.com> <2574b1d30809150709n38627b43va5a4e04fa5ec85df@mail.gmail.com> <3DABE53F-A150-4720-8139-D05BD57AE613@shlang.com>
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="===============0416177635=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

On Mon, Sep 15, 2008 at 9:02 PM, Stanislav Shalunov <shalunov@shlang.com>wrote:

>   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.
>
[Ye (Yale)]
I generally agree with you that a simple prefer-faster-peer strategy may not
be the best for application performance.  However, without knowing any
bandwidth information, or given inaccurate inputs, I would rather believe
that it is more difficult for the peer to make the optimal decision.

>
>   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.
>
[Ye (Yale)]
Conceptually, capacity matching is the efficient way to utilize system
resouce.  The intuition (not rigorous) is as follows.  Say, a leecher with
download capacity DR chooses to download from a seed with upload limit UR,
where DR<UR.  This strategy may destroy the possibility that the seed could
actually serve another client which has higher download capcity
DR'=UR.  Thus, some of the system upload capacity (UR-DR) might
be unnecessarilly wasted.

Formal analysis indicates: through bandwidth matching, a file sharing swarm
(essentially a content distribution system) is able to achieve the best
average download rate (distriuting speed).

>
> 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.
>
[Ye (Yale)]
You are right that the linear response seems to be somehow improving the
fast peers but ignoring the slow and regular. The gain on the average
number largely comes from the tail.

Anyway, the good thing is, from the recent results of our P4P field test, we
have observed improvement for both fast peers and slow peers, probably due
to general improvement on system efficiency.

>  --
> Stanislav Shalunov <http://shlang.com/>
>
> [image: Hacking Startups] <http://feeds.feedburner.com/~r/shlang/~6/1>
>
>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi