Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 13 June 2008 16:23 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 DBC623A67F4; Fri, 13 Jun 2008 09:23:48 -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 6023A3A67F4 for <p2pi@core3.amsl.com>; Fri, 13 Jun 2008 09:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 vZIpojX6c7nj for <p2pi@core3.amsl.com>; Fri, 13 Jun 2008 09:23:46 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 251163A67B3 for <p2pi@ietf.org>; Fri, 13 Jun 2008 09:23:45 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5DGOBH3021750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 11:24:13 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DGO86O025534; Fri, 13 Jun 2008 11:24:08 -0500 (CDT)
Message-ID: <48529F2B.1080400@alcatel-lucent.com>
Date: Fri, 13 Jun 2008 11:24:11 -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: Laird Popkin <laird@pando.com>
References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <B023B3B2-5A5C-4B2A-B950-5C342B863A7E@pando.com>
In-Reply-To: <B023B3B2-5A5C-4B2A-B950-5C342B863A7E@pando.com>
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "p2pi@ietf.org" <p2pi@ietf.org>
Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]
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

Laird Popkin wrote:
> Yes, I certainly didn't mean to imply that there was any problem with
> the "oracle" approach or the ALTO proposal - I am a strong supporter
> of this model. My only concern is that we don't limit our discussion
> to the one signaling protocol that was used as an example. My 
> apologies if my (perhaps overly detailed) email came across as more 
> negative than I intended. :-)

Laird: No worries, it did not.  In fact, you bring a lot of
relevant discussion points.  One thing that caught my eye was:

> It's important to keep in mind that optimizing peer selection for p2p
> transfers has the most impact for large swarms. That is, if there
> are only 20 people on the planet that can serve you data, (1) it
> doesn't take too long to connect to all of them so optimized peer
> selection doesn't save much peer connection time, and (2) the odds of
> any of them being in the same ISP is fairly low, so optimized peer
> selection doesn't affect data flow much.

This is very true for large swarms.  However, aside from a BitTorrent-
like P2P configuration, consider the whole notion of service
discovery in VoIP P2P networks in the context of finding the
nearest -- say -- video mail peer to deposit my video mail, and
if that resource is replicated in the DHT, to find the
nearest peer that can serve it.  Here, the number of people
interested in this video mail resource is low, probably the
sender and the receiver only, and maybe a finite number of
others who the first two may want to share the resource with.
But the network could benefit from keeping the traffic localized.

> This is why we shifted (in the P4P approach) away from the more
> obvious IP list approach to moving the guidance into the Tracker's
> memory [...]

Thanks; I did read your paper in preparation for the workshop,
but either I did not read it closely enough, or some epiphany
occurred on reading your email to make things more clear on
the tracker approach.

Ciao.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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