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

[Song Haibin <melodysong at huawei.com>]

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 aFrom ietf-bounces at ietf.org  Tue Oct 14 09:15:22 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3E0B93A681D;
	Tue, 14 Oct 2008 09:15:22 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at 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 at 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 at 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 at 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 at huawei.com>
Subject: RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
In-reply-to: <48F36E15.2000408 at alcatel-lucent.com>
To: "'Vijay K. Gurbani'" <vkg at alcatel-lucent.com>, vidyan at qualcomm.com
Message-id: <005401c92dd6$fafbff80$250ca40a at 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
X-Mailman-Approved-At: Tue, 14 Oct 2008 09:15:21 -0700
Cc: p2pi at ietf.org, 'IESG IESG' <iesg at ietf.org>, ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at 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.

>gree.

>> 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


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


> 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


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf