Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs

Enrico Marocco <enrico.marocco@telecomitalia.it> Mon, 02 June 2008 22: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 20FCE28C21A; Mon, 2 Jun 2008 15:23:03 -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 A183D28C21A for <p2pi@core3.amsl.com>; Mon, 2 Jun 2008 15:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 OlU2BNcsxAmG for <p2pi@core3.amsl.com>; Mon, 2 Jun 2008 15:23:01 -0700 (PDT)
Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id AA23F3A6A71 for <p2pi@ietf.org>; Mon, 2 Jun 2008 15:15:38 -0700 (PDT)
Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 00:15:37 +0200
Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 00:15:37 +0200
Received: from [172.16.82.10] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.115) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 3 Jun 2008 00:15:36 +0200
Message-ID: <484470F1.7000105@telecomitalia.it>
Date: Tue, 03 Jun 2008 00:15:13 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: Laird Popkin <laird@pando.com>
References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com>
In-Reply-To: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com>
X-Enigmail-Version: 0.95.0
X-OriginalArrivalTime: 02 Jun 2008 22:15:37.0120 (UTC) FILETIME=[2F1C9A00:01C8C4FE]
Cc: "ramit@pando.com" <ramit@pando.com>, "p2pi@ietf.org" <p2pi@ietf.org>, "p4pwg@yahoogroups.com" <p4pwg@yahoogroups.com>
Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs
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="===============0740901616=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Laird Popkin wrote:
> As we discussed last week at the IETF P2Pi Workshop, here are a list of
> some of the ways that IETF standards can potentially help P2P
> applications make better network decisions, and thus help ISPs. This
> isn't a complete list, but I hope that it's at least a useful starting
> point for a discussion.

It seems to me that this turned out to be a two-sided problem.  On the
one hand, it is clear that applications on the endpoints are in the
worst position to make optimal network decisions; a first part of the
solution should thus consist of a mechanism to defer such decisions to
external entities (not necessarily controlled by ISPs, as e.g. in the
case of Ono, where the redirection service is provided by Akamai
servers). The need for such a mechanism was claimed by several papers
[4,26,28,29] and, AFAIR, received little objection (the one that I
recall was the "hot potato" thing, where the external entity providing
the peer selection service would be able to place sort of DDOS attacks
against specific targets/networks).

On the other hand, how to compute best paths is a separate part of the
problem; topology/cost/congestion notification, cache identification,
usage metrics, and the like all fall in this category and, at this time,
are probably more research topics than engineering issues.

Right now, I think the IETF should focus on the first part of the
problem, the front-end of a generic third-party peer selection service
p2p applications can query in order to make better choices; innovation
and competition will then happen on the back-end of such a service
without requiring standardization in the first place.

[*] References at
http://www.ietf.org/mail-archive/web/p2pi/current/msg00005.html

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