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

Song Haibin <> Wed, 15 October 2008 01:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 522273A685C; Tue, 14 Oct 2008 18:06:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0009E3A6A8E; Tue, 14 Oct 2008 18:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q8EFsL2ul3Kb; Tue, 14 Oct 2008 18:06:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B51F73A67C0; Tue, 14 Oct 2008 18:06:43 -0700 (PDT)
Received: from (szxga01-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <>; Wed, 15 Oct 2008 09:07:38 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <>; Wed, 15 Oct 2008 09:07:38 +0800 (CST)
Received: from s64081 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <>; Wed, 15 Oct 2008 09:07:38 +0800 (CST)
Date: Wed, 15 Oct 2008 09:07:37 +0800
From: Song Haibin <>
In-reply-to: <>
To: 'Laird Popkin' <>
Message-id: <008501c92e62$6a644a40$>
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:, 'IESG IESG' <>,
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Laird Popkin []
>Sent: Tuesday, October 14, 2008 10:48 PM
>To: Song Haibin
>Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
>I'd like to second this, and also make sure that the relationship between
>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
>to connect. But once peers are exchanging data, the p2p network/protocol
>TCP) pretty much takes over, because those protocols address the actual
>throughput between peers, real-time congestion, etc., that are not
>by ALTO.
>I should also make clear that ALTO does not (and cannot) control the p2p
>Generally ALTO guidance should provide better than average peer connections
>(which is certainly what we saw in the P4P field tests), so the p2p
>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
>it is highly likely to keep using that connection no matter what ALTO says.
>on the flip side, if the ALTO-recommended peer connections aren't providing
>data needed, the p2p network will use other peers as data sources. And, of
>p2p networks must continue to operate where ALTO guidance is unavailable.

Yes, actually I have the same thought with you.

Song Haibin

>- Laird Popkin, CTO, Pando Networks
>  mobile: 646/465-0570
>----- Original Message -----
>From: "Song Haibin" <>
>To: "Vijay K. Gurbani" <>om>,
>Cc:, "IESG IESG" <>rg>,
>Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York
>Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
>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,
>only network policy and topology related (e.g. peer preference) information
>is allowed. I don't think we are designing BitTorrent here.
>Song Haibin
>p2pi mailing list

p2pi mailing list