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
- [p2pi] Information in an ALTO protocol Enrico Marocco
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Vinay Aggarwal
- Re: [p2pi] Information in an ALTO protocol Lars Eggert
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol chsoft
- Re: [p2pi] Information in an ALTO protocol Vinay Aggarwal
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Sebastian Kiesel
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Fabio Hecht
- Re: [p2pi] Information in an ALTO protocol Song Haibin
- Re: [p2pi] Information in an ALTO protocol Vijay K. Gurbani
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Spencer Dawkins
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol David R Oran
- Re: [p2pi] Information in an ALTO protocol Reinaldo Penno
- Re: [p2pi] Information in an ALTO protocol Lisa Dusseault
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Reinaldo Penno
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Salman Abdul Baset
- Re: [p2pi] Information in an ALTO protocol Griffiths, Chris
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Woundy, Richard
- Re: [p2pi] Information in an ALTO protocol stefano previdi
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Ye WANG
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Nicholas Weaver
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Philip Levis
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Stanislav Shalunov
- Re: [p2pi] Information in an ALTO protocol Ye WANG
- Re: [p2pi] Information in an ALTO protocol The 8472
- Re: [p2pi] Information in an ALTO protocol Laird Popkin
- Re: [p2pi] Information in an ALTO protocol Salman Abdul Baset