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

Song Haibin <melodysong@huawei.com> Wed, 15 October 2008 01:06 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 522273A685C; Tue, 14 Oct 2008 18:06:46 -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 0009E3A6A8E; Tue, 14 Oct 2008 18:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599]
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 q8EFsL2ul3Kb; Tue, 14 Oct 2008 18:06:43 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B51F73A67C0; Tue, 14 Oct 2008 18:06:43 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R00LHW9SQQF@szxga01-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +0800 (CST)
Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R00ITU9SQN2@szxga01-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +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 <0K8R00LAR9SPE2@szxml05-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +0800 (CST)
Date: Wed, 15 Oct 2008 09:07:37 +0800
From: Song Haibin <melodysong@huawei.com>
In-reply-to: <889695024.364101223995681087.JavaMail.root@dkny.pando.com>
To: 'Laird Popkin' <laird@pando.com>
Message-id: <008501c92e62$6a644a40$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: AckuDR/QVdQVuCJUROi4xWSX61IkHAAVRonw
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

>-----Original Message-----
>From: Laird Popkin [mailto:laird@pando.com]
>Sent: Tuesday, October 14, 2008 10:48 PM
>To: Song Haibin
>Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
(alto)
>
>I'd like to second this, and also make sure that the relationship between
ALTO
>and the application is clear.
>
>From the application perspective, ALTO is a source of useful guidance (i.e.
>network topology and "cost" model) that can help the p2p network find good
peers
>to connect. But once peers are exchanging data, the p2p network/protocol
(and
>TCP) pretty much takes over, because those protocols address the actual
>throughput between peers, real-time congestion, etc., that are not
addressed
>by ALTO.
>
>I should also make clear that ALTO does not (and cannot) control the p2p
network.
>Generally ALTO guidance should provide better than average peer connections
>(which is certainly what we saw in the P4P field tests), so the p2p
networks
>will be motivated to use ALTO guidance when they can because it's in their
>interests to do so. But there will always be cases that are exceptions. For
>example, if a p2p network is getting fantastic data delivery between two
peers,
>it is highly likely to keep using that connection no matter what ALTO says.
And,
>on the flip side, if the ALTO-recommended peer connections aren't providing
the
>data needed, the p2p network will use other peers as data sources. And, of
course,
>p2p networks must continue to operate where ALTO guidance is unavailable.
:-)

Yes, actually I have the same thought with you.

BR
Song Haibin


>- Laird Popkin, CTO, Pando Networks
>  mobile: 646/465-0570
>
>----- Original Message -----
>From: "Song Haibin" <melodysong@huawei.com>
>To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>om>, vidyan@qualcomm.com
>Cc: p2pi@ietf.org, "IESG IESG" <iesg@ietf.org>rg>, ietf@ietf.org
>Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York
>Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
(alto)
>
>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

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