Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Song Haibin <melodysong@huawei.com> Tue, 14 October 2008 08:29 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 A0A3F3A6ABA; Tue, 14 Oct 2008 01:29:27 -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 22A363A6A11; Tue, 14 Oct 2008 01:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 41dQagUMMHAl; Tue, 14 Oct 2008 01:29:25 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 430D23A6936; Tue, 14 Oct 2008 01:29:25 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P0017GZL2DD@szxga02-in.huawei.com>; Tue, 14 Oct 2008 16:29:27 +0800 (CST)
Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00EIYZL2LL@szxga02-in.huawei.com>; Tue, 14 Oct 2008 16:29:26 +0800 (CST)
Received: from s64081 ([10.164.12.37]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8P00AOGZL2C2@szxml05-in.huawei.com>; Tue, 14 Oct 2008 16:29:26 +0800 (CST)
Date: Tue, 14 Oct 2008 16:29:30 +0800
From: Song Haibin <melodysong@huawei.com>
In-reply-to: <48F36E15.2000408@alcatel-lucent.com>
To: "'Vijay K. Gurbani'" <vkg@alcatel-lucent.com>, vidyan@qualcomm.com
Message-id: <005401c92dd6$fafbff80$250ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Thread-index: AcktS08fvjdzLHQrQc2p10LG53ipqQAicAwQ
Cc: p2pi@ietf.org, 'IESG IESG' <iesg@ietf.org>, ietf@ietf.org
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Hi Vijay,

>Narayanan, Vidya wrote:
>> communications.  In fact, all that is important in this context is
>> that the overlay acts as a rendezvous for sharing such information.
>
>I think the disconnect we may be having is that you view
>ALTO as a peer description protocol; it is not.  Other
>protocols like BitTorrent, for example, are more suited to
>this, and they do exactly what you want.  In a BitTorrent
>overlay (swarm), the overlay knows exactly which peer is
>contributing which content, which peer has which chunks,
>the download/upload ratio, the time the peer joined the swarm,
>whether the peer is choked or unchoked, whether the peer has
>a public port, etc.  ALTO is not out to replace BitTorrent.  What
>ALTO is providing are better strategies for peer selection.
>
>For instance, it is not ALTO that gets to decide which peer is
>hosting which content and what the contributions of that peer
>to the overlay are.  However, it is ALTO's job to provide
>information to a querying peer allowing it to determine wisely
>where it will download the content from.

Totally agree.

>> I'm afraid that would be a mistake.  It actually doesn't matter if we
>> don't agree today on the exact types of information that can be
>> shared.  It is important that we have a protocol that allows peers to
>> publish ALTO related information.  Having this protocol be
>> extensible would allow for any type of information to be carried in
>> it.
>
>So far, no one on the list has proposed that ALTO be a peer
>description and publication protocol.  So based on the discussion
>we have had since (essentially the workshop in) May 2008 on the
>p2pi list, I would hesitate to add in the charter something that
>participants have not expressed any preference for (i.e., a
>deliverable on peers publishing their information.)

IMHO, not every type of information can be carried in the ALTO protocol, but
only network policy and topology related (e.g. peer preference) information
is allowed. I don't think we are designing BitTorrent here.

Regards!
Song Haibin


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