Re: [p2pi] Information in an ALTO protocol

Fabio Hecht <hecht@ifi.uzh.ch> Mon, 18 August 2008 14:49 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 D8D4628C195; Mon, 18 Aug 2008 07:49:35 -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 8A8EB28C14C for <p2pi@core3.amsl.com>; Mon, 18 Aug 2008 07:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 Mxoq1bTl334y for <p2pi@core3.amsl.com>; Mon, 18 Aug 2008 07:49:33 -0700 (PDT)
Received: from nikolai.ifi.uzh.ch (nikolai.ifi.uzh.ch [130.60.155.10]) by core3.amsl.com (Postfix) with ESMTP id 0CC2028C1A2 for <p2pi@ietf.org>; Mon, 18 Aug 2008 07:49:28 -0700 (PDT)
Received: from authenticated sender hecht by nikolai.ifi.uzh.ch (postfix) with ESMTP id 068C02A6B33; Mon, 18 Aug 2008 16:49:29 +0200 (CEST)
From: Fabio Hecht <hecht@ifi.uzh.ch>
To: Vinay Aggarwal <vinay@net.t-labs.tu-berlin.de>
In-Reply-To: <20080811165443.GB18911@net.t-labs.tu-berlin.de>
References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <E3361EDE-EDC6-4EF0-9249-B87B6C2D349C@nokia.com> <df9ced400808110837n57c79866se83369300812975e@mail.gmail.com> <20080811165443.GB18911@net.t-labs.tu-berlin.de>
Organization: Universität Zürich
Date: Mon, 18 Aug 2008 16:49:29 +0200
Message-Id: <1219070969.6961.37.camel@bart2>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
X-Virus-Scanned: ClamAV 0.93.1/8053/Mon Aug 18 14:42:12 2008 on nikolai.ifi.uzh.ch
X-Virus-Status: Clean
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Hello,

in this case, would an ALTO Server query other ALTO Servers to gather
this information? Because, from an ISP point of view, the ALTO Server
would not know what the last-hop bandwidth is for every other peer.
Would the protocol then be the same used by the overlay applications?

Regards

Fabio

On Mon, 2008-08-11 at 18:54 +0200, Vinay Aggarwal wrote:
> Hi,
> 
> regarding bandwidth information,
> here is a paper that shows that taking last-hop bandwidth into account
> helps to improve the download performance of peers. In fact, bandwidth
> comes out to be the significant factor to improve download times.
> 
> Vinay Aggarwal, Obi Akonjang, Anja Feldmann. Improving User and ISP
> Experience through ISP-aided P2P Locality. In Proceedings of 11th IEEE
> Global Internet Symposium 2008 (GI'08)
> 
> The paper (and other related papers) are available at:
> http://www.net.t-labs.tu-berlin.de/research/isp-p2p/
> 
> It would make sense to provide information about the "uplink" bandwidth,
> as that is much smaller than "downlink" bandwidth, atleast in case of DSL,
> and is thus a limiting factor.
> 
> The ALTO can consider the uplink bandwidth of peers, and use it in
> combination with geographic or parent AS information to sort the peers.
> 
> I agree that some ISPs prefer to keep traffic within their network,
> while other ISPs would sometimes welcome traffic going to other ISPs.
> This is especially true for large ISPs, who get paid for traffic flowing
> to other networks, typically their customers. 
> 
> Depending on the circumstances, an ISP can prefer peers either with
> large uplink or those within its network, or better still, both!
> Important is that the user should experience improved performance. 
> 
> IMHO, considering just the actual uplink bandwidth will help a great
> deal. While estimating the currently "available" bandwidth would be
> still better, that is a lot harder to achieve. But if that is reasonably
> possible to do for the ALTO server, that is a much better alternative
> than having the peer probing for the real available bandwidth and
> picking the best one.
> 
> Vinay.
> 
> 

-- 
Fabio Hecht

University of Zurich - Department of Informatics (IfI)
Binzmühlestrasse 14 CH-8050 Zürich, Switzerland
Ph.: +41 44 6357129 / 6350892  Fax: +41 44 6356809
VoIP sip:hecht@ifi.uzh.ch

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi