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

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Wed, 15 October 2008 15:20 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 8D6053A69A0; Wed, 15 Oct 2008 08:20:52 -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 798C13A69A0; Wed, 15 Oct 2008 08:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 j1rY7COJQPya; Wed, 15 Oct 2008 08:20:50 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E91133A68CC; Wed, 15 Oct 2008 08:20:49 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9FFKmZk010124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 10:20:48 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9FFKlmi025935; Wed, 15 Oct 2008 10:20:48 -0500 (CDT)
Message-ID: <48F60A4F.3010604@alcatel-lucent.com>
Date: Wed, 15 Oct 2008 10:20:47 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: vidyan@qualcomm.com
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <48EFA1B7.7010508@alcatel-lucent.com> <BE82361A0E26874DBC2ED1BA244866B92763750C@NALASEXMB08.na.qualcomm.com> <48F36E15.2000408@alcatel-lucent.com> <BE82361A0E26874DBC2ED1BA244866B927637717@NALASEXMB08.na.qualcomm.com>
In-Reply-To: <BE82361A0E26874DBC2ED1BA244866B927637717@NALASEXMB08.na.qualcomm.com>
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "p2pi@ietf.org" <p2pi@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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Narayanan, Vidya wrote:
> Hi Vijay, I am not at all talking about reinventing what BitTorrent 
> can do or even remotely about any actual p2p application itself.  I 
> am only talking about peer selection.  However, I think there is a 
> critical difference between what I view as contributing to peer 
> selection and what the current proposed charter does.

Vidya: Thank you for your response. I think we are converging
to the crucial difference in this thread.  This is a good thing.
More inline.

> Peer selection is important to ISPs from a network utilization 
> perspective and to peers themselves from a performance perspective. 
> That automatically makes peer selection a function of multiple 
> aspects - a) information that some service providers may decide to 
> share with the peers, b) information that peers decide to make 
> available about themselves to other peers for this purpose, and, c) 
> any measurements peers may do on their own.  The current charter 
> definition (and from what I can tell based on your response below) 
> only seems to allow for a).  I would agree that c) is out of scope of
>  ALTO and something that peers can additionally do.  I strongly 
> believe that b) should be part of the ALTO work.

I believe that incorporating (b) expands the charter quite a bit,
whereas the consensus since the first BoF was for narrowing
it down.  I will also note that the feedback expressed on the
list does not appear to view ALTO as a peer description protocol.

To be sure, I am not unsympathetic to (b), it seems like a great
problem to solve, it's just that ALTO may not be the best place
to solve this problem.

In the end, maybe the ADs can decide a way forward.

> This functionality itself is application agnostic and requires an
> interoperable solution for it to be beneficial.  This has nothing to
> do with content itself; it is purely about sharing information that
> helps with peer selection.

Protocols like BitTorrent already contain elements such that
the peers know enough about other peers that the overlay is
functioning.  The information that BitTorrent (and other P2P
overlays) do not have is topology and policies.  This is where
ALTO is urged to fill a crucial gap, at least initially.

Since the IETF/MIT workshop, the problem outlined for what has
become ALTO has been how to choose the peers wisely.  We (i.e.,
the BoF/list participants) have been diligent to note that
ALTO is not completely dependent on service providers; third
parties can run ALTO servers as well; and these servers can use
ad-hoc techniques like Ono (which was discussed yesterday on
the list) or some form of Internet Coordinate Systems to derive
a topology.  We have also been diligent to note that ALTO is an
additional service provided to an overlay; the overlay will
continue to function without it (albeit in a bit of a sub-optimal
manner.)  We have also noted given a choice between a service
provider run ALTO server and a third party ALTO server, that
peers will naturally gravitate towards the ALTO server
that provides them the best information over a long period
of time.

In other words, we have covered substantial grounds since
the IETF/MIT workshop and the Dublin BoF based on the
premise of the problem as the group has understood it.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi