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
- Re: [p2pi] Refining the ALTO problem statement [W… Enrico Marocco
- Re: [p2pi] Refining the ALTO problem statement [W… Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement [W… stefano previdi
- Re: [p2pi] Refining the ALTO problem statement [W… Stephane Bortzmeyer
- Re: [p2pi] Refining the ALTO problem statement [W… Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement [W… Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement [W… Stephane Bortzmeyer
- Re: [p2pi] Refining the ALTO problem statement [W… Stephane Bortzmeyer
- Re: [p2pi] Refining the ALTO problem statement [W… Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement [W… Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement [W… Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement [W… Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement [W… Enrico Marocco
- Re: [p2pi] Refining the ALTO problem statement [W… Enrico Marocco
- Re: [p2pi] Refining the ALTO problem statement [W… Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement [W… Y. R. Yang
- Re: [p2pi] Refining the ALTO problem statement [W… Stephane Bortzmeyer
- Re: [p2pi] Refining the ALTO problem statement [W… stefano previdi