Re: [p2pi] Information in an ALTO protocol

chsoft@gmail.com Mon, 11 August 2008 15:37 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 139263A6E6F; Mon, 11 Aug 2008 08:37: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 72EB33A6E6F for <p2pi@core3.amsl.com>; Mon, 11 Aug 2008 08:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Z1SsJXunq0cd for <p2pi@core3.amsl.com>; Mon, 11 Aug 2008 08:37:19 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 591593A67B6 for <p2pi@ietf.org>; Mon, 11 Aug 2008 08:37:17 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1905231rvf.49 for <p2pi@ietf.org>; Mon, 11 Aug 2008 08:37:19 -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:cc:in-reply-to:mime-version:content-type:references; bh=3oX8HEZ6V9YlugGVuAt8roYInltB5IxsYL886eK/u60=; b=wWdTCvZDPwxDtA0NBoPgvV0GEkNcMvGTIDi3KV4PZvulyOukpHB0dbNuVl/r23U6B+ tbbTKWqiRKcDBwzDuOv089LXBpIJLDyuPuQIfLRqLmmgVDakKT3ScG0+wt/Lm30xxe1+ Ix22pM2gluo+XUgrsUdwkBqgFVuyA73LP2EK4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=FbpK7OZhXrYC5kQdv017OMJemwLyp5eRZdmibWOQqZAr1xKj3afud8Pcwa48Nr+nlp ZFIfbtVp6zC2EOkd9Rk9ITguK56zizHb/xZ1DWmz3UMpngtIrWGxxHb8CYvPXHw+FNMD 5BH0BLrKwRymUtuVUN/TFOGaKTVlImdqIHbQs=
Received: by 10.140.165.21 with SMTP id n21mr3586991rve.244.1218469039129; Mon, 11 Aug 2008 08:37:19 -0700 (PDT)
Received: by 10.141.45.11 with HTTP; Mon, 11 Aug 2008 08:37:18 -0700 (PDT)
Message-ID: <df9ced400808110837n57c79866se83369300812975e@mail.gmail.com>
Date: Mon, 11 Aug 2008 23:37:18 +0800
From: chsoft@gmail.com
To: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <E3361EDE-EDC6-4EF0-9249-B87B6C2D349C@nokia.com>
MIME-Version: 1.0
References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <E3361EDE-EDC6-4EF0-9249-B87B6C2D349C@nokia.com>
Cc: "p2pi@ietf.org" <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="===============1749180528=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

I think Vinay may mean the last-hop upload bandwidth for the local peer to
select among candidates.
The we can imagine two phases.
At first phase ALTO may prefer to response with remote peers with larger
nominal last-hop cap.
Secondly, it leaves to the local peer to probe for the real available
bandwidth among them and take the best scheduling for piece retrieval.
Maybe it will drop some peers with low consumption upload bandwidth.

On Mon, Aug 11, 2008 at 11:00 PM, Lars Eggert <lars.eggert@nokia.com> wrote:

> Hi,
>
> On 2008-8-11, at 17:35, ext Vinay Aggarwal wrote:
>
>> I think an estimate of "last-hop bandwidth" can be an interesting metric
>> of information for peer selection.
>> It has been shown that selecting peers with high last-hop bandwidth lead
>> to improvements in download performance. And this is information that is
>> rather hard for peers to find out themselves. As far as I can see, it
>> also satisfies all the bars set up by the ALTO service.
>>
>
> Uplink or downlink bandwidth?
>
> Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or
> the currently available fraction of it? The latter would be something that I
> doubt an ALTO box can have an accurate view of, since it changes on short
> timescales.
>
> Could you share a reference to papers that show that that information is
> beneficial?
>
> Thanks,
> Lars
>
> _______________________________________________
> 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