Re: [p2pi] After-BoF charter

Enrico Marocco <enrico.marocco@telecomitalia.it> Thu, 14 August 2008 17:30 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 5809C28C16D; Thu, 14 Aug 2008 10:30:45 -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 F06643A6C6C for <p2pi@core3.amsl.com>; Thu, 14 Aug 2008 10:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.147
X-Spam-Level:
X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 tqCMl4RkTYMw for <p2pi@core3.amsl.com>; Thu, 14 Aug 2008 10:30:43 -0700 (PDT)
Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 82B813A6AF0 for <p2pi@ietf.org>; Thu, 14 Aug 2008 10:30:42 -0700 (PDT)
Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 19:30:45 +0200
Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 19:30:45 +0200
Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 14 Aug 2008 19:30:44 +0200
Message-ID: <48A46A5F.4080606@telecomitalia.it>
Date: Thu, 14 Aug 2008 19:24:47 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: John Leslie <john@jlc.net>
References: <489B47A0.1050507@telecomitalia.it> <EAFFEDBC-D318-4A37-A307-31C2F134DBD6@nokia.com> <20080808161710.GA25453@verdi>
In-Reply-To: <20080808161710.GA25453@verdi>
X-OriginalArrivalTime: 14 Aug 2008 17:30:45.0229 (UTC) FILETIME=[7BB4C1D0:01C8FE33]
Cc: Lisa Dusseault <lisa@osafoundation.org>, "p2pi@ietf.org" <p2pi@ietf.org>
Subject: Re: [p2pi] After-BoF charter
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: multipart/mixed; boundary="===============0155532447=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

John Leslie wrote:
>    The speed of convergence to optimal is the critical issue: we want
> a "better-than-random" initial set of peers to try (and possibly an
> ordered list to try if they prove unsatisfactory.
> 
>    I think adding the word "inital" would help:
> "
> " information to perform better-than-random initial peer selection.

Yes, that's better.

>>> When the WG considers standardizing schemas, measures or other
>>> information that the ALTO service could provide, the following
>>> criteria are important to ensure real feasibility.
>>>
>>> - Can an ALTO service technically provide that information?
>>>
>>> - Is the ALTO service willing to obtain and divulge that information?
>>>
>>> - Is it information that some client will find useful?
> 
>    Good criteria, but I'd suggest uniformity of the indefinite article:
> 
> - "an" ALTO service technically provide
> - "an" ALTO service willing to obtain and divulge
> - "a" client will find useful

Ok.

>>> Protocols used for peer selection optimization will carry information
>>> related to the topology and the policies of the querying peer's
>>> network (i.e. queries on behalf of other peers are not allowed).
> 
>    We should perhaps be careful about this last prohibition. I'm not
> sure the obvious mechanism (matching the source IP address of a query)
> is wise (though I certainly wouldn't prohibit implementations from
> trying it).
> 
>    There are obvious potential benefits from letting particular
> trackers read an ISP's policies (by prior arrangement, usually). A
> blanket prohibition of this seems unnecessary.

That's true, but, on the other hand, allowing uncontrolled third-party
queries would be a privacy nightmare, for both users and ISPs. I've
personally had a discussion with Stanislav, who said that having peers
doing the ALTO query and passing the response back to a BitTorrent
tracker would not be too much of a hassle, so, probably, given the costs
that controlling third-party queries in a reasonable way would imply, it
could be wise to just forbid them. However, I would really like to hear
what other people think about this, especially on the P2P side.

>>> It is reasonable to expect that applications will use such protocols
>>> to discover Autonomous System (AS) numbers and approximate geographic
>>> location of peers hosting the needed resources,
> 
>    I don't even _understand_ this.
> 
>    Current trackers _do_ try to find these pieces of information, but
> IMHO they're suboptimal substitutes for information ISPs could provide.
> I see no reason to include such text in a charter.

Right, we have let them in exactly because that's the kind of
information a third-party non-ISP ALTO service provider could provide
(ip2location and "looking glass" web services already do, just in a
non-standard way). We could get rid of those pieces of information, but
that would probably reduce the suitability of ALTO for non-ISPs.

-- 
Ciao,
Enrico
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi