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

Laird Popkin <laird@pando.com> Tue, 14 October 2008 14:48 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 1C0FD28C1DD; Tue, 14 Oct 2008 07:48:14 -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 ECC4F28C1DD; Tue, 14 Oct 2008 07:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.264
X-Spam-Level:
X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
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 z1OKE6jdFPD0; Tue, 14 Oct 2008 07:48:11 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 87EE028C11A; Tue, 14 Oct 2008 07:48:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 598AEE10B62; Tue, 14 Oct 2008 10:48:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH+RvH1WpNch; Tue, 14 Oct 2008 10:48:01 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1B2E0E10B2A; Tue, 14 Oct 2008 10:48:01 -0400 (EDT)
Date: Tue, 14 Oct 2008 10:48:01 -0400 (EDT)
From: Laird Popkin <laird@pando.com>
To: Song Haibin <melodysong@huawei.com>
Message-ID: <889695024.364101223995681087.JavaMail.root@dkny.pando.com>
In-Reply-To: <005401c92dd6$fafbff80$250ca40a@china.huawei.com>
MIME-Version: 1.0
X-Originating-IP: [10.10.20.77]
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

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. :-)

- 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