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

Song Haibin <melodysong@huawei.com> Tue, 03 June 2008 06:22 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 6D8383A6B81; Mon, 2 Jun 2008 23:22:19 -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 E31063A6B9D for <p2pi@core3.amsl.com>; Mon, 2 Jun 2008 23:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 4Iwsw0-moP9Y for <p2pi@core3.amsl.com>; Mon, 2 Jun 2008 23:22:17 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id 3F54628C12D for <p2pi@ietf.org>; Mon, 2 Jun 2008 23:21:38 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1V00AEIIVGTI@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1V0036KIVG5Z@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST)
Received: from s64081 ([10.164.9.76]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1V00I26IVF1T@szxml04-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST)
Date: Tue, 03 Jun 2008 14:18:51 +0800
From: Song Haibin <melodysong@huawei.com>
In-reply-to: <p06240606c46a2c26d09d@[129.46.226.27]>
To: 'Ted Hardie' <hardie@qualcomm.com>, 'Enrico Marocco' <enrico.marocco@telecomitalia.it>, 'Laird Popkin' <laird@pando.com>
Message-id: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Thread-index: AcjFBcdXQmFNW/5dRJ+pc/FlIV/b6AAOSdSg
Cc: ramit@pando.com, p2pi@ietf.org, 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

>-----Original Message-----
>From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Ted
>Hardie
>Sent: Tuesday, June 03, 2008 7:06 AM
>To: Enrico Marocco; Laird Popkin
>Cc: ramit@pando.com; p2pi@ietf.org; p4pwg@yahoogroups.com
>Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs
>
>At 3:15 PM -0700 6/2/08, Enrico Marocco wrote:
>>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
>
>Of course you can recast this  as "So we should make sure that
>there are mechanisms that allow them to make more optimal decisions.
>The facilities which provide this information need not be controlled
>by the ISPs, but might be third party services which indicate
>cost/topology/congestion or some profile mix of the three."
>
>To my way of thinking, that makes it easier to consider the API
>design, as it is not so much an API that says "What's the best
>choice right now?"  but "What's the best X (flow pattern, topology,
>price)".  The second set of questions is sufficiently more modular
>that it is both easier to get right and, at least in my opinion,
>more interesting.
>Just  my two cents,
>Ted

I think it depends on whether the P2P application or the party that provides
peer selection information service makes the final choice. IMO, the peer
selection information service should provide information to help the p2p
application to determine best paths or peers, but not itself makes the final
choice.

-Song Haibin



_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi