From mailman-admin@ietf.org Thu Apr 1 18:43:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09930 for ; Thu, 1 Apr 2004 18:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99dt-0001nh-Ey for p2prg-archive@lists.ietf.org; Thu, 01 Apr 2004 16:22:29 -0500 Date: Thu, 01 Apr 2004 11:23:26 -0500 Message-ID: <20040401162326.11029.16607.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: p2prg-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, p2prg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for p2prg-archive@lists.ietf.org: List Password // URL ---- -------- p2prg@ietf.org enimbi https://www.ietf.org/mailman/options/p2prg/p2prg-archive%40lists.ietf.org From exim@www1.ietf.org Tue Apr 6 07:06:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03922 for ; Tue, 6 Apr 2004 07:06:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoPW-0005GZ-1s for p2prg-archive@odin.ietf.org; Tue, 06 Apr 2004 07:06:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36B6U1G020243 for p2prg-archive@odin.ietf.org; Tue, 6 Apr 2004 07:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoPV-0005GQ-NX for p2prg-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 07:06:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03803 for ; Tue, 6 Apr 2004 07:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoPR-0000Xj-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 07:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAo6W-0005bA-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 06:46:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAncU-0002iO-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 06:15:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnYt-0008VU-QC; Tue, 06 Apr 2004 06:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnYH-0008Go-5D for p2prg@optimus.ietf.org; Tue, 06 Apr 2004 06:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28726 for ; Tue, 6 Apr 2004 06:11:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnYD-0001pa-00 for p2prg@irtf.org; Tue, 06 Apr 2004 06:11:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAn8i-0006ab-00 for p2prg@irtf.org; Tue, 06 Apr 2004 05:45:05 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BAmob-0004dB-00 for p2prg@irtf.org; Tue, 06 Apr 2004 05:24:18 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i369ODK02254; Tue, 6 Apr 2004 11:24:13 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i369O8D06759; Tue, 6 Apr 2004 11:24:08 +0200 (MEST) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA19181; Tue, 6 Apr 2004 11:23:38 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Apr 2004 11:24:00 +0200 Message-ID: <5BE5F1117AEDD5118BFC0000D11EA39CC8C52C@blns205e.bln.icn.siemens.de> From: Andersen Frank-Uwe To: "'Alexandre Alessi'" <17975@lci.upf.tche.br>, p2prg@irtf.org Subject: AW: [P2Prg] Edges of internet Date: Tue, 6 Apr 2004 11:23:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Alexandre, since no one answered so far, I dare to give you my best guess only = (though I do not know that author Shirky): If the statement was slightly re-written (just exchanging two words), = like this "provide the nodes in the edges of the net significant = autonomy", it would be much clearer and correspond to what is generally = believed to be true for P2P networks, wouldn't it? But again, just my 2 cents, and why not send him (Shirky = clay@shirky.com (?)) a mail about this? We would all like to see the = answer to this conundrum. - Frank-Uwe > -----Urspr=FCngliche Nachricht----- > Von: p2prg-admin@ietf.org [mailto:p2prg-admin@ietf.org] Im=20 > Auftrag von Alexandre Alessi > Gesendet: Freitag, 26. M=E4rz 2004 19:54 > An: p2prg@irtf.org > Betreff: [P2Prg] Edges of internet >=20 >=20 > Some authors (like Shirky) say that one of the conditions for=20 > a system to be > named P2P is that the nodes of the net "provide the nodes in=20 > the edges of > the significant net autonomy", what do they mean? >=20 >=20 > _______________________________________________ > P2prg mailing list > P2prg@irtf.org > https://www.ietf.org/mailman/listinfo/p2prg >=20 _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Tue Apr 6 22:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25538 for ; Tue, 6 Apr 2004 22:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2T6-0005d5-CU for p2prg-archive@odin.ietf.org; Tue, 06 Apr 2004 22:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37278KQ021640 for p2prg-archive@odin.ietf.org; Tue, 6 Apr 2004 22:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2T6-0005cx-8u for p2prg-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 22:07:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25422 for ; Tue, 6 Apr 2004 22:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2T2-0005oO-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 22:07:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB1j3-0007S3-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 21:19:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB0fp-0001Na-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 20:12:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB0fp-0003Em-1B for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 20:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0fi-0004xy-P7; Tue, 06 Apr 2004 20:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0fU-0004wV-2J for p2prg@optimus.ietf.org; Tue, 06 Apr 2004 20:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16697 for ; Tue, 6 Apr 2004 20:11:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0fS-0001JP-00 for p2prg@ietf.org; Tue, 06 Apr 2004 20:11:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB05I-0003QS-00 for p2prg@ietf.org; Tue, 06 Apr 2004 19:34:25 -0400 Received: from law10-f119.law10.hotmail.com ([64.4.15.119] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BAz2D-0004CE-00 for p2prg@ietf.org; Tue, 06 Apr 2004 18:27:09 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Apr 2004 15:26:39 -0700 Received: from 202.138.119.197 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 06 Apr 2004 22:26:39 GMT X-Originating-IP: [202.138.119.197] X-Originating-Email: [anshuman21@hotmail.com] X-Sender: anshuman21@hotmail.com From: "anshoo upadhyaya" To: p2prg@ietf.org Date: Tue, 06 Apr 2004 22:26:39 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 06 Apr 2004 22:26:39.0395 (UTC) FILETIME=[3ACB3F30:01C41C26] Subject: [P2Prg] p2p security Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_30_40,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60


Hi all,

   Can anybody please tell me about the links to various papers on p2p seciruty. I have to complete one research paper on the topic as part of my subject( System & Network Security) research paper project.

Thanx very much.

regards,

ANSHUMAN UPADHYAY ,
STUDENT, B. Tech( III yr),
DA-IICT,
GANDHINAGAR
www.da-iict.org

 

 


Buzz on your screen! Download on your screen. Keep yourself smiling! _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Wed Apr 7 00:37:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09742 for ; Wed, 7 Apr 2004 00:37:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4nr-0000bf-W0 for p2prg-archive@odin.ietf.org; Wed, 07 Apr 2004 00:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i374ahNx002327 for p2prg-archive@odin.ietf.org; Wed, 7 Apr 2004 00:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4nr-0000bN-P8 for p2prg-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 00:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09621 for ; Wed, 7 Apr 2004 00:36:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB4np-0006WT-00 for p2prg-web-archive@ietf.org; Wed, 07 Apr 2004 00:36:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB3wf-0007GZ-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 23:41:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB2km-0000i5-00 for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 22:25:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB2el-00045e-7C for p2prg-web-archive@ietf.org; Tue, 06 Apr 2004 22:19:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2ea-0001WY-8m; Tue, 06 Apr 2004 22:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2dc-0001H8-Qu for p2prg@optimus.ietf.org; Tue, 06 Apr 2004 22:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27611 for ; Tue, 6 Apr 2004 22:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2dZ-0007b2-00 for p2prg@ietf.org; Tue, 06 Apr 2004 22:17:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB24O-0001ug-00 for p2prg@ietf.org; Tue, 06 Apr 2004 21:41:37 -0400 Received: from mail010.syd.optusnet.com.au ([211.29.132.56]) by ietf-mx with esmtp (Exim 4.12) id 1BB0tC-0002WH-00 for p2prg@ietf.org; Tue, 06 Apr 2004 20:25:59 -0400 Received: from localhost.karma (c211-28-250-119.eburwd5.vic.optusnet.com.au [211.28.250.119]) by mail010.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i370OIB05621; Wed, 7 Apr 2004 10:24:19 +1000 Received: by localhost.karma (Postfix, from userid 500) id 00C7125F; Wed, 7 Apr 2004 10:24:08 +1000 (EST) Date: Wed, 7 Apr 2004 10:24:07 +1000 From: Andrew Clausen To: anshoo upadhyaya Cc: p2prg@ietf.org Subject: Re: [P2Prg] p2p security Message-ID: <20040407002406.GA16037@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Accept-Language: en,pt Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Apr 06, 2004 at 10:26:39PM +0000, anshoo upadhyaya wrote: > Can anybody please tell me about the links to various papers on p2p > seciruty. I have to complete one research paper on the topic as part of my > subject( System & Network Security) research paper project. Here's one: http://dbpubs.stanford.edu/pub/showDoc.Fulltext?lang=en&doc=2003-1&format=pdf&compression= Cheers, Andrew _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Wed Apr 7 02:47:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18327 for ; Wed, 7 Apr 2004 02:47:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6q7-0006r7-RS for p2prg-archive@odin.ietf.org; Wed, 07 Apr 2004 02:47:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i376lBNQ026354 for p2prg-archive@odin.ietf.org; Wed, 7 Apr 2004 02:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6q7-0006qz-Lj for p2prg-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 02:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18195 for ; Wed, 7 Apr 2004 02:47:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB6q3-0006eQ-00 for p2prg-web-archive@ietf.org; Wed, 07 Apr 2004 02:47:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB60S-0006QK-00 for p2prg-web-archive@ietf.org; Wed, 07 Apr 2004 01:53:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BB4mJ-0006L4-00 for p2prg-web-archive@ietf.org; Wed, 07 Apr 2004 00:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4mD-00006m-He; Wed, 07 Apr 2004 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4lX-0008UK-1b for p2prg@optimus.ietf.org; Wed, 07 Apr 2004 00:34:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09003 for ; Wed, 7 Apr 2004 00:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB4lU-0006F3-00 for p2prg@ietf.org; Wed, 07 Apr 2004 00:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB3v9-00072U-00 for p2prg@ietf.org; Tue, 06 Apr 2004 23:40:12 -0400 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BB2jz-0000cw-00 for p2prg@ietf.org; Tue, 06 Apr 2004 22:24:35 -0400 Received: from power (c-24-1-214-127.client.comcast.net[24.1.214.127]) by comcast.net (sccrmhc13) with SMTP id <20040407022405016003h0u0e>; Wed, 7 Apr 2004 02:24:05 +0000 Reply-To: From: "Raymond Gao" To: Subject: FW: [P2Prg] p2p security Date: Tue, 6 Apr 2004 21:24:05 -0500 Message-ID: <000e01c41c47$6630dab0$927ba8c0@power> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C41C1D.7D5AD2B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C41C1D.7D5AD2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit fyi, -----Original Message----- From: Raymond Gao [mailto:raygao@comcast.net] Sent: Tuesday, April 06, 2004 9:21 PM To: 'anshoo upadhyaya' Subject: RE: [P2Prg] p2p security Check P2PJ's website ( http://p2pjournal.com ) http://p2pjournal.com/main/current_issue.htm - There are several papers in various issues. http://p2pjournal.com/main/resources.htm - Contain many different people's articles on P2P technology. http://p2pjournal.com/main/security.htm - As well as, I have a section on security. (Some of it needs to be updated.) And, also check out http://p2pjournal.com/main/sharealink.php to share you links with other people. -Ray -----Original Message----- From: p2prg-admin@ietf.org [mailto:p2prg-admin@ietf.org] On Behalf Of anshoo upadhyaya Sent: Tuesday, April 06, 2004 5:27 PM To: p2prg@ietf.org Subject: [P2Prg] p2p security Hi all, Can anybody please tell me about the links to various papers on p2p seciruty. I have to complete one research paper on the topic as part of my subject( System & Network Security) research paper project. Thanx very much. regards, ANSHUMAN UPADHYAY , STUDENT, B. Tech( III yr), DA-IICT, GANDHINAGAR www.da-iict.org _____ Buzz on your screen! Download on your screen. Keep yourself smiling! _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg ------=_NextPart_000_000F_01C41C1D.7D5AD2B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
fyi,
 
-----Original Message-----
From: Raymond Gao=20 [mailto:raygao@comcast.net]
Sent: Tuesday, April 06, 2004 = 9:21=20 PM
To: 'anshoo upadhyaya'
Subject: RE: [P2Prg] p2p=20 security

Check=20 P2PJ's website ( http://p2pjournal.com )=20
http://p2pjournal.c= om/main/current_issue.htm -=20 There are several papers in various issues.
http://p2pjournal.com/m= ain/resources.htm -=20 Contain many different people's articles on P2P = technology.
http://p2pjournal.com/ma= in/security.htm -=20 As well as, I have a section on security. (Some of it needs to be=20 updated.)
 
And,=20 also check out http://p2pjournal.com/= main/sharealink.php to=20 share you links with other people.
 
-Ray
 
-----Original Message-----
From:=20 p2prg-admin@ietf.org [mailto:p2prg-admin@ietf.org] On Behalf Of = anshoo=20 upadhyaya
Sent: Tuesday, April 06, 2004 5:27 = PM
To:=20 p2prg@ietf.org
Subject: [P2Prg] p2p = security


Hi all,

   Can anybody please tell me about the links to various = papers=20 on p2p seciruty. I have to complete one research paper on the = topic as=20 part of my subject( System & Network Security) research paper = project.

Thanx very much.

regards,

ANSHUMAN UPADHYAY ,
STUDENT, B. Tech( III yr),
DA-IICT,
GANDHINAGAR
www.da-iict.org

 

 


Buzz on your screen! Download on your screen. Keep yourself = smiling!=20 _______________________________________________ P2prg mailing list=20 P2prg@irtf.org=20 https://www.ietf.org/mailman/listinfo/p2prg ------=_NextPart_000_000F_01C41C1D.7D5AD2B0-- _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Fri Apr 16 10:28:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12321 for ; Fri, 16 Apr 2004 10:28:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUJJ-0007Ng-SE for p2prg-archive@odin.ietf.org; Fri, 16 Apr 2004 10:27:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GERHr7028372 for p2prg-archive@odin.ietf.org; Fri, 16 Apr 2004 10:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU9g-0004JY-ES for p2prg-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 10:17:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11621 for ; Fri, 16 Apr 2004 10:17:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEU9e-0000jm-7o for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 10:17:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEU8c-0000gB-00 for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 10:16:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEU7p-0000c8-00 for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 10:15:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU0e-0008Hz-Q1; Fri, 16 Apr 2004 10:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETx5-0006TE-Lb for p2prg@optimus.ietf.org; Fri, 16 Apr 2004 10:04:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10043 for ; Fri, 16 Apr 2004 10:04:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETx3-000046-8M for p2prg@ietf.org; Fri, 16 Apr 2004 10:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETw5-0007mq-00 for p2prg@ietf.org; Fri, 16 Apr 2004 10:03:17 -0400 Received: from mail11.ntu.edu.sg ([155.69.5.163]) by ietf-mx with esmtp (Exim 4.12) id 1BETvN-0007iX-00 for p2prg@ietf.org; Fri, 16 Apr 2004 10:02:33 -0400 Received: from mail03.student.main.ntu.edu.sg ([155.69.5.167]) by mail11.ntu.edu.sg with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Apr 2004 22:02:00 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423BB.6330CE3A" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 16 Apr 2004 22:01:56 +0800 Message-ID: <1053947AAA70F54AA4ECD7887A3A6D890131E5D2@mail03.student.main.ntu.edu.sg> Thread-Topic: stoc04 paper Thread-Index: AcQju2DhwL3v0zX4SNi6+9tpeEkERA== From: "#ZENG JIANYANG#" To: X-OriginalArrivalTime: 16 Apr 2004 14:02:00.0617 (UTC) FILETIME=[635DE190:01C423BB] Subject: [P2Prg] stoc04 paper Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_60_70,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C423BB.6330CE3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all =20 Who have studied the paper on STOC'04, "Know thy Neighbor's Neighbor: = the Power of Lookahead in Randomized P2P Networks"?=20 I found that it is a little difficult to understand LEMMA 3.3 in this = paper,can somebody help me make it clear? =20 Thanks a lot. =20 =20 Regards, Jianyang =20 ------_=_NextPart_001_01C423BB.6330CE3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,=20 all
 
Who have studied the=20 paper on STOC'04, "Know thy Neighbor's Neighbor: = the Power=20 of Lookahead in Randomized P2P Networks"?=20
I found that it is a little difficult to = understand=20 LEMMA 3.3 in this paper,can somebody help me make it=20 clear?
 
Thanks a lot.
 
 
Regards,
Jianyang
 

------_=_NextPart_001_01C423BB.6330CE3A-- _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Fri Apr 16 22:32:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28506 for ; Fri, 16 Apr 2004 22:32:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfb1-0002an-FR for p2prg-archive@odin.ietf.org; Fri, 16 Apr 2004 22:30:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H2UJ4o009961 for p2prg-archive@odin.ietf.org; Fri, 16 Apr 2004 22:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfXS-0001YD-FH for p2prg-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 22:26:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28222 for ; Fri, 16 Apr 2004 22:26:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEfXP-00066c-7N for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 22:26:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEfWS-00063j-00 for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 22:25:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEfWA-00060g-00 for p2prg-web-archive@ietf.org; Fri, 16 Apr 2004 22:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfNB-0006eg-Be; Fri, 16 Apr 2004 22:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEfHx-0005kg-S5 for p2prg@optimus.ietf.org; Fri, 16 Apr 2004 22:10:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27166 for ; Fri, 16 Apr 2004 22:10:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEfHu-0004qo-KR for p2prg@ietf.org; Fri, 16 Apr 2004 22:10:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEfGx-0004o1-00 for p2prg@ietf.org; Fri, 16 Apr 2004 22:09:36 -0400 Received: from mail003.syd.optusnet.com.au ([211.29.132.144]) by ietf-mx with esmtp (Exim 4.12) id 1BEfGU-0004k9-00 for p2prg@ietf.org; Fri, 16 Apr 2004 22:09:06 -0400 Received: from localhost.karma (c211-28-250-119.eburwd5.vic.optusnet.com.au [211.28.250.119]) by mail003.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i3H28V421028; Sat, 17 Apr 2004 12:08:34 +1000 Received: from satisfactory (satisfactory [192.168.0.1]) by localhost.karma (Postfix) with ESMTP id 8FA2625F; Sat, 17 Apr 2004 12:08:28 +1000 (EST) Received: by satisfactory (Postfix, from userid 500) id 5962746AAF; Sat, 17 Apr 2004 12:08:27 +1000 (EST) Date: Sat, 17 Apr 2004 12:08:27 +1000 From: Andrew Clausen To: #ZENG JIANYANG# Cc: p2prg@ietf.org Subject: Re: [P2Prg] stoc04 paper Message-ID: <20040417020826.GC639@gnu.org> References: <1053947AAA70F54AA4ECD7887A3A6D890131E5D2@mail03.student.main.ntu.edu.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1053947AAA70F54AA4ECD7887A3A6D890131E5D2@mail03.student.main.ntu.edu.sg> X-Accept-Language: en,pt User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, Apr 16, 2004 at 10:01:56PM +0800, #ZENG JIANYANG# wrote: > Who have studied the paper on STOC'04, "Know thy Neighbor's Neighbor: the > Power of Lookahead in Randomized P2P Networks"? > I found that it is a little difficult to understand LEMMA 3.3 in this > paper,can somebody help me make it clear? Which version are you looking at? The version I found with Google didn't have a Lemma 3.3. Cheers, Andrew _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Thu Apr 22 03:12:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07579 for ; Thu, 22 Apr 2004 03:12:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYKP-000660-RD for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 03:08:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M78vwi023426 for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 03:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYGk-00037H-3D for p2prg-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 03:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07116 for ; Thu, 22 Apr 2004 03:05:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGYGg-0006fP-3c for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 03:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYG0-0006R1-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 03:04:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGYEe-0006CN-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 03:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY54-0006vU-Cc; Thu, 22 Apr 2004 02:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY3k-0005yo-PE for p2prg@optimus.ietf.org; Thu, 22 Apr 2004 02:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06381 for ; Thu, 22 Apr 2004 02:51:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGY3g-0003lE-T6 for p2prg@ietf.org; Thu, 22 Apr 2004 02:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGY2x-0003Xi-00 for p2prg@ietf.org; Thu, 22 Apr 2004 02:50:55 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BGY24-0003K5-00 for p2prg@ietf.org; Thu, 22 Apr 2004 02:50:01 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3M6o1M18507; Thu, 22 Apr 2004 08:50:01 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3M6o0M13797; Thu, 22 Apr 2004 08:50:00 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id IAA19111; Thu, 22 Apr 2004 08:49:26 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Apr 2004 08:49:35 +0200 Message-ID: <5BE5F1117AEDD5118BFC0000D11EA39CC8C5C6@blns205e.bln.icn.siemens.de> From: Andersen Frank-Uwe To: "'p2prg@ietf.org '" , "'p2prg-mobility@cs.umd.edu '" Date: Thu, 22 Apr 2004 08:49:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C42833.3A272F8A" Subject: [P2Prg] Interim Results of the mobility subgroup Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C42833.3A272F8A Content-Type: text/plain Dear all, enclosed please find the latest interim results of the mobility subgroup. The reason for sending it to the main mailing list is that I would like to propose (in accordance with Bill) for all the subgroups to put together what has been discussed and concluded during the past 8 month. In my opinion, the result of this process can easily be a draft of the type "problem statement". This would make for a nice input for San Diego, and we could also discuss everything on a side-meeting there. I will gladly help to put it all together. Do the other subgroups have similar collections of interim results? Cheers, Frank-Uwe p.s. to the "mobility" subgroup fellows: please let me know if I forgot to mention the name of any contributors in our document. ------_=_NextPart_000_01C42833.3A272F8A Content-Type: application/octet-stream; name="p2prg-mobility-initial-research_v1_6.txt" Content-Disposition: attachment; filename="p2prg-mobility-initial-research_v1_6.txt" Content-Transfer-Encoding: quoted-printable IRTF P2PWG Sub-Group: p2p in mobile environments Frank-Uwe Andersen Luca Caviglione Oliver Waldhorst Overall research directions and problem classification (in preparation of a "problem statement" draft) Introduction The subgroup is researching issues that arise from the combination of p2p techniques with mobility. Mobility in this sense comprises mobile devices and their requirements, mobile infrastructure and its IP mobility restrictions (as well as its potential capability to support p2p), algorithms and system design / architecture. Since mobility itself constitutes a cross-issue for all layers, it does also affect many, if not all, parts of p2p. This research is related to mobile ad hoc networking, mobile IP and routing. The purpose is to identify the functional areas of p2p systems that are "affected" by mobility issues. A tentative structure for our object of research is shown below. p2p-Mobility 1. Wireless mobility o Optimizations + Bandwidth variations + BER / Wireless link outage + Proxying o Non-wireless mobility (initially out of scope) 2. Infrastructure-based o Cellular environment + restraints in 3G packet oriented network 3. Non-Infrastructure (pure ad-hoc) 4. Routing o Interference of overlay and routing mechanisms o Effects of higher layers onto lower layers o Ontological routing such as location based (initially out of scope) o Effects of lower layers onto higher layers + Mobility mgmt. using mobile IP + Effects of multihoming + Effects of multicasting =09 5. Content and p2p services / functions + Discovery / Searching + Download + Bootstrapping + Content protection 6. Security + Broadcast-nature of wireless link (privacy problem) 7. Devices o Limitations: Memory, CPU, .. + Data / Route / Query Caching on mobile node 8. Specific Systems + JXTA (for mobile environments?) The items of interest are each described in the subsequent passages. Definition of mobility There are different types of mobility, ranging from user mobility (handled e.g. by SIP) to terminal mobility (corresponds to the mobile IP term "mobile host" all the way up to network mobility=20 which is currently treated in the NEMO group. At this point in time, the p2prg mobility subgroup does not restrict itself to one type of mobility. Since the definition of a p2p overlay is a basic precondition to understand many of the items, it is therefore given first. Definition of overlay (provisory) One of the possible way to define the "overlay", even if general, might be the following. It is a more general way of defining it, since it leaves aside any specific technique to generate the overlay (almost every p2p system does it on its own way). =20 "The overlay is the sum of all distributed state information in a p2p network, containing but not limited to connectivity information, location/name of superpeers, closest peers, adjacency".=20 This definition is probably not yet complete. By using this definition it will also allow us to describe p2p-mobility in a simple and straightforward way. The key reasoning concerns about derived propriety of the overlay due to the presence of a mobility component.=20 =20 "In p2p-mobility, the sum of all distributed state information might be fast time varying (due to mobility) and highly unreliable (due to link, again mobility and limited devices...)" To summarize the key concepts: p2p overlays (as defined above) are blind regarding the topology of sub-layers. This is usually not a big problem with participants that do not change their location. With mobile participants, however, one may at least expect efficiency decreases due to increased "update signalling". The overlay principle itself may still work, but if the mobility is increased to a certain level, the network is slowed down or collapses. 1. Wireless mobility Wireless mobility reflects in a well-defined behavior. Mobile nodes might encounter the following problems strictly related to the lower layers peculiarities.=20 Wireless links, especially when used in an urban context, might be subjected on major problems related to multi-path fading, cell overcrowd and connectivity loss due to obstacles or both harsh indoor - outdoors environments. Of course, protocol stack layered architecture performs a kind of "behavioral hiding" of such phenomena but higher layers will be influenced. As a matter of facts, when connection oriented technologies such as TCP are employed major problems might arise. The joint use of TCP with mobile p2p is not mandatory, but in the vision of a full IP convergence, such as in UMTS - 3G cellular environments, some considerations should be useful. Physical bandwidth fluctuations will reflects in transport issues and consequently, in "rough power" for exchanging data among different applications or devices. When using devices this peculiarity must be taken in to account allowing slight adjustments or improvement to the overlay network.=20 Nevertheless, wireless networking might be used jointly a wired infrastructure: some rules could be investigated allowing to find the right balance when p2p is used in a mixed scenario. Wireless oriented limitations or countermeasures might be too restrictive when applied in a context where about the 99% of peers are participating via wired technologies. Conversely, a "overlay region" heavy populated by mobile-wireless peers might be assumed as not preferential for routing or caching but still need to be integrated and managed in the overall architecture avoiding fragmentation issues and at the same time might be used with attention.=20 Wireless Link Outage=20 While participating a p2p architecture, a mobile node might experience an intermittent connection.=20 2. Infrastructure-based (to be done) o Cellular environment + restraints in 3G packet oriented network =09 The overall architecture of the 3GPP based packet domain=20 3. Non-Infrastructure (pure ad-hoc) Matching of overlay and network topology According to the provisory definition, the overlay comprises of connectivity information, especially information about closest nodes and network adjacency. Since the overlay is "blind regarding the topology of sub-layers", in general closest neighbors in the (application layer) overlay are are not physical neighbors in the ad hoc network. Physical neighbors are known on the network layer, as a routing protocol for ad hoc networks provides routes comprising of multiple hops between physical neighbors. A mismatch between overlay and network layer neighbors results in the employment of long network routes for overlay communication. Evidently, this wastes scarce resources like radio bandwidth and energy. Furthermore, maintenance of long routes requires increased activity by the routing protocol. To reduce mismatches between overlay and network layer topology, a well-defined API is required to provide information from the network layer (or even lower layers) to the peer-to-peer system for overlay construction. Suitable information include, e.g., proximity information (i.e., the route length in hops), or information about route failures. Overlay construction Network layer information should be used when initially connecting a peer to the overlay. E.g., proximity information provided from the network layer using the API can be used to select the closest network layer neighbor from a set of candidate peer for initial connection. Alternatively, the initial connection can be established to an arbitrary peer, and successively optimized by selecting more appropriate peers determined by suitable combination of overlay adjacency information with network proximity information. Overlay maintenance Closest network layer neighbors may frequently change due to user mobility. Similar to routing protocols for ad hoc networks, that react to topology changes on the network layer, the overlay must be adopted to changing physical topology. The peer-to-peer system can be instantly informed about topology changes (e.g., route failures) using the API to the network layer. In case of a topology change, two approaches are possible similar to ad hoc routing. First, the peer-to-peer system can act pro-actively, and reconstruct overlay=09 connections matching the changed network topology. Second, the peer- to-peer system can mark the involved overlay connections as stale, but delay reconstruction until the overlay connection is used for communication. Thus, overlay connections will be established on demand. Which approaches is preferable depends on the traffic pattern generated by the peer-to-peer application. Overlay Mutability The frequency of adaption can be adjusted according to some rules, e.g., requirements of the peer-to-peer application, the resources available in the ad hoc networt etc. Some rules of thumb will follow: =09 Keep a physical overlay connection only as long as it is=20 active, i.e., two nodes exchange information using this connection. Try to provide a reasonable matching between active overlay routes and the physical layer using the=20 mechanisms specified above. When a route becomes inactive, discard it, but keep information to enable fast re-establishment of overlay connectivity (maybe this is what you call potential overlay). Epidemic information dissemination / gossiping Frequently changing closest neighbors make an ad hoc network attractive for gossip-style protocols for information dissemination. In such protocols, information will be transfered between closest neighbors either pro-actively or on demand. Since closest neighbors change due to user mobility, the information will spread in the ad hoc network like an infectious disease. Depending on the requirements of the peer-to-peer application, expensive construction of overlays spanning the entire ad hoc network can be avoided by employment of gossip-style protocols. 4. Routing Preface: Mutual interference of adjacent layers=20 Higher layers are sometimes the "victims" of routing decisions for instance when mobile-IP is jointly used with a p2p paradigm: mobile- IP mechanisms might destroy part of the overlay (e.g. the binding updates don't come quickly enough). Conversely, the self-organized characteristics of the p2p overlaid network might move traffic bloats around the networked environment in an unpredictable manner.=20 Interference of overlay and routing mechanisms Particular problems might arise when different routing mechanisms and overlay mechanisms (depending on specific p2p system) start to interfere. Higher layers influence routing decisions and in a similar way as routing decisions will reflect in particular traffic patterns. This may happen if, for example, a p2p network user is additionally using mobile IP. During movement, numerous mobile IP binding updates may be necessary. At the same time, dozens (hundreds) of peer connections exist, and they all need to stay connected. If the "playground" is a mediated p2p scenario, orphan peers will need to find another network entry point. This procedure resembles the "first node problem" when a peer needs to know a first node to join the p2p- network. In this perspective, routing and overlay interference will reflect in not obvious problems such as "cache size" and "timing" problems. Overlay infrastructure will in some way influence the routing and the taxonomy of the routing infrastructure: table dimension, entry lifetime, time out value. Higher layers decisions and routing interference=20 In addition, problems might arise when the overlaid network is used without any consideration of the underlying infrastructure. Consider an organizational model based upon "common resource interest", for instance a particular file or a piece of mobile code located in another country (e.g. accessed via a trans-oceanic link). A large population of interested peers will move a huge amount of traffic in particular network zones. The ability of each peers' application level to take decisions influence the "routing". Then there is a mutual interference: overlaid network usage will reflect in particular traffic patterns within the network while routing strategies will affect the overlaid topology, as previously explained in mobile IP. In a mobility perspective, previous aspects must be taken in to account: a traffic load might be not routed in a high-mobility populated zone because it could create high congestion and unmanageable network overload. The end-to-end principle In [2], it is stated that the "End to end transparency" principle suffers from the introduction of private addressing schemes, NAT and firewalls. The network cannot be regarded as symmetric any more, longer symmetric, so that communication between two addresses is possible if the communication session originates from one end but not from the other. This impedes the deployment of new peer-to-peer services, and some 'push' services where the server in a client- server arrangement originates the communication session. Whether a new routing system either can or should seek to restore this transparency is an open issue. A related issue is the extent to which end user applications should seek to control the routing of communications to the rest of the network. 5. Content and p2p services / functions Basic p2p services comprise at least a search function and a download function.=20 =09 One impact that mobility might have on the search + download functions is that in case of a location-based search function, the list of peers that have been listed and optimized by the search function to provide the desired content may not be valid anymore after a location change of the client peer. While during the initial search, the client peer received for example the address of a peer in the same high-speed local area network. After the client peer changes its point of network attachment, other server peers might be optimal for the desired download, but they remain unknown to the client peer which is still connected to the old server peer(s). 6. Security=20 When using a p2p infrastructure there are major concerns related to security. Confidential information might be routed via other peers. Clearly, the p2p paradigm raises security issues, which are more=20 evident when combining p2p to mobility. Probably, some=20 countermeasures should be taken into account when writing the "software", but adding some "constitutive features" in the framework itself will bring some benefits.=20 One of the most important characteristics of p2p is the opportunity of "juxtaposing" an overlay network on the physical infrastructure. Consequently, there will be two main security branches: one related to the overlay algorithms and one related to the underlying network infrastructure. If the networked scenario supports IPsec, L2 encryption or Secure Socket Layer (SSL), maybe the security layer provided by the "p2p-os" on top might be thinner or simply more coordinated with the lower layers.=20 If the "overlay" interacts with the lower layers some tricks might be applied, such as strict source routing to bypass insecure peers or prevent risky network zones (e.g., a region where WEP-like algorithms are not applied).=20 This reasoning probably reduces p2p benefits by isolating instead of connecting peers and should therefore be seen as a back-up solution.=20 Native security might as well be implemented in the "layer that implements p2p" and this will branch the problem space in two subspaces: the implementations themselves (maybe platform dependent) and the protocol-architecture specification (maybe technology- standard dependent). Overlay-based routing (sould we call it "application level routing"?) might be powered with techniques like the Onion-Routing approach [1] but, transposed to higher layers.=20 7. Devices Mobile devices classification may vary from a simple phone to a complete personal computing device connected with an IEEE 802.11 based interfaces. Multiple Bluetooth-based pico-networks could be interconnected via mediation points and a 3G-like cell phone could bridge everything to the Internet. In this highly heterogeneous perspective, some ranking mechanism should take in to account: a rank could be provided by mediating the CPU power, the storage (for routing table and caches) the maximum amount of available connections, the available link speed etc. 8. Specific Systems (to be done) Sources: [1] http://www.onion-router.net/ =20 [2] http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-02.txt ------_=_NextPart_000_01C42833.3A272F8A-- _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Thu Apr 22 16:05:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24822 for ; Thu, 22 Apr 2004 16:05:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk9A-0002PS-17 for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 15:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJk88Z009262 for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 15:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjkB-00073h-A6 for p2prg-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 15:20:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20702 for ; Thu, 22 Apr 2004 15:20:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjk8-0002Nk-2I for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:20:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjjE-00027R-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:19:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjif-0001rE-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:18:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPi-00075u-L3; Thu, 22 Apr 2004 14:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjIA-0004up-0N for p2prg@optimus.ietf.org; Thu, 22 Apr 2004 14:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17424 for ; Thu, 22 Apr 2004 14:51:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjI5-0001f6-4x for p2prg@ietf.org; Thu, 22 Apr 2004 14:51:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjH8-0001Ny-00 for p2prg@ietf.org; Thu, 22 Apr 2004 14:50:20 -0400 Received: from [216.65.116.22] (helo=sm1255.hostcentric.net) by ietf-mx with esmtp (Exim 4.12) id 1BGjGi-00016i-00 for p2prg@ietf.org; Thu, 22 Apr 2004 14:49:52 -0400 Received: (qmail 30403 invoked by uid 107); 22 Apr 2004 18:31:20 -0000 Received: from c-66-41-30-194.mn.client2.attbi.com (HELO bitbucket) (justin@onionnetworks.com@66.41.30.194) by 216.65.116.22 with RC4-MD5 encrypted SMTP; 22 Apr 2004 18:31:20 -0000 From: Justin Chapweske To: discuss@jxta.org Cc: decentralization@yahoogroups.com, p2prg@ietf.org, p2prg@ietf.org In-Reply-To: <4087F52D.8020607@sun.com> References: <1082578771.4045.332.camel@bog> <40870FD9.40705@sun.com> <1082606019.8379.36.camel@bog> <1082614980.13116.135.camel@shall.internal.vwaty.com> <4087688B.4070308@sun.com> <1082643092.8379.56.camel@bog> <4087F52D.8020607@sun.com> Content-Type: text/plain Message-Id: <1082659634.8379.221.camel@bog> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 22 Apr 2004 13:47:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [P2Prg] Dynamic Networking Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have absolutely no problem with HTTP, being one of the "team of two > plus a > few" who released Tomcat to the world in '99. The problem I have with > the > HTTP application programming model is entirely in the realm of > deployment. > Server as largely assumed to be reachible via static addresses, IP. My > interests > are in "everything is a server, everthing is a client" such that > servers can > be instantiated, provissioned, and reclaimed dynamically w/ no harm > and in > fact "to great advantage" to the application network. In this model > the app > developer is literally constrained as to what the deployment network > looks > like. With JXTA, the app developer *owns* the network, can change it > as the > need arises, etc. BTW, this is the very epiphany I had that clued me > in that > there had to be a better way moving forward. I'm CC'ing this message to decentralization and p2p-hackers to engage the larger community on this interesting topic. James, I heartily agree with your goal of transcending the limitations of static addresses and allowing the network to be much more dynamic. However, I think we have different approaches for achieving this goal. My approach is to treat dynamic networking as a naming or URI problem. JXTA appears to take the approach that dynamic networking is a routing or messaging problem. Now, there are multiple levels at which one can solve dynamic networking from a naming perspective. The first level corresponds to solving the problem at the IP level using multicast and anycast addresses. A wonderful example of this is zeroconf/rendezvous. By allowing URIs/IP addresses to be resolved to any valid machine on the LAN, transparent dynamic networking is now enabled by any application that sits on top of IP and DNS. Of course, the limitation of dynamic networking at the IP level is that it only works for "anycast" type services where a number of nodes can provide the desired service. But, it does not provide for point-to-point dynamic networking services where a single specific node (possibly roaming) can provide the desired service. To solve the issue of contacting a single, possibly roaming, node with no reliable static IP address, we can look at the next layer up the naming stack - DNS. To solve dynamic networking at the DNS level, we make use of two different approaches: Akamai-style request routing via DNS, and dynamic DNS that routes to a single roaming node. The Akamai approach provides the anycast type functionality where a single name may resolve to any number of valid endpoints that can facilitate the desired service. The dynamic DNS approach allows a single roaming node to be contacted via a sturdy identifier where ever it may be. Now, the main limitations of the DNS approach is the reachability of nodes that are behind NAT/Firewalls and are unroutable via IP and the centralization of DNS infrastructure. The first issue can be solved by something like IPv6/Teredo or simply introducing public rendezvous points that proxy TCP streams to hidden nodes. This could be easily accomplished with SSH port forwarding. The second problem of centralization of DNS infrastructure is probably not an issue for most applications since all you need is a single static server to handle the DNS serving, and you can easily have a fully decentralized name space underneath your top level registered domain. Now, assuming that the NAT and centralization limitations of DNS are too limiting for your application, or you simply don't feel comfortable developing an application at the DNS level, the next layer in the naming stack is URIs. In order to provide dynamic networking at the URI naming level, you simply need to switch a portion of your URIs to non-DNS-based URIs. There is no need to switch all of your URIs to be location independent, and indeed in Swarmcast we freely mix static HTTP URIs with location independent UUID URIs. Location independent URIs, by their very nature, imply support for both an anycast model, as well as a single-end-node or point-to-point model. The only difference between these two cases is the number of authoritative sources that can provide the service associated with the URI in a secure fashion. In an anycast model, a number of nodes can authoritatively serve a URI, and in a point-to-point model, only a single end node can authoritatively serve a URI. Now, even though these location-independent URIs are not HTTP URIs, it doesn't mean that they can't still be served via HTTP. There are two ways to serve a non-HTTP URI via HTTP, the first is by proxying, and the second is by providing explicit URI resolution services. I'll skip over proxying for now and focus on URI resolution services. URI resolution services are very straight-forward. They are basically a mechanism to discover other equivalent URIs for a given URI. The goal of URI resolution in the context of dynamic networking is to resolve a location independent URI into one or more authoritative HTTP URIs. This concept is laid out in THTTP/RFC 2169 and the Content-Addressable Web (http://open-content.net/specs/draft-jchapweske-caw-03.html), though the latter is in severe need of updating/refinement. Under the covers, there are numerous ways that one can implement URI resolution, but I believe one should be careful to hide the details of the URI resolution specifics and allow developers to focus on simply naming and consuming resources. For example: o Gnutella provides a form of URI resolution by mapping keywords to URNs, then using THTTP to further resolve to specific HTTP end points. With magnet-URIs, people have done exactly that. o DHT's are an obvious candidate for URI resolution under the covers - I would love to see a DHT that provides a simple RFC 2169/THTTP interface for looking up URIs. o JXTA could also be used under the covers for URI resolution, using its security and group communication features as a value add. Once the URI is resolved, the end-user application would establish a direct connection to the resulting URI(s) to finish the transaction. Now, the last piece of this whole thing is HTTP proxying and caching. Now, even after mentioning earlier how DNS/HTTP-based URIs may have certain limitations, this all goes out the window when you consider HTTP caching semantics. HTTP defines very clear semantics for allowing a non-point-of-origin node to service a request directly and it can also fulfill requests for non-HTTP URIs. This allows fully dynamic URI-based networking to take place hidden completely behind the abstraction of an HTTP proxy. This approach also allows additional features like automatic-failover to be automatically added to applications w/o any modification to the original application My point behind this is that routing and messaging are not the answer to facilitating dynamic networking. An end application should not need to be concerned with how to route a message to a dynamic receiver, nor should it be concerned with protocols at a higher level than absolutely necessary - If you need dynamic networking on a LAN, use zeroconf. If you need dynamic networking among publicly addressable servers, use DNS. If you need dynamic networking to NAT'd nodes, then use URIs and HTTP. No matter which route you take, the code in the end-application is largely the same - it understands IP, DNS, and URIs. Imagine if Google required every client that connected with their service to participate in the proprietary Google query routing/messaging system. Of course, they chose to hide their service behind the abstraction of HTTP and their web services. In closing, JXTA has some great features, but end applications should be able to access JXTA services w/o knowing or caring that they are JXTA services. Peace, -Justin _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Thu Apr 22 16:13:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25227 for ; Thu, 22 Apr 2004 16:13:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkAH-0002jD-HP for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 15:47:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJlHGg010482 for p2prg-archive@odin.ietf.org; Thu, 22 Apr 2004 15:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjm1-0008Bn-P8 for p2prg-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 15:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20833 for ; Thu, 22 Apr 2004 15:22:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjly-0002vh-Jt for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:22:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjkz-0002e5-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:21:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjk0-0002Mn-00 for p2prg-web-archive@ietf.org; Thu, 22 Apr 2004 15:20:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPj-00076J-1d; Thu, 22 Apr 2004 14:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjID-0004ur-FK for p2prg@optimus.ietf.org; Thu, 22 Apr 2004 14:51:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17429 for ; Thu, 22 Apr 2004 14:51:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjI8-0001fU-KM for p2prg@ietf.org; Thu, 22 Apr 2004 14:51:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjHA-0001O8-00 for p2prg@ietf.org; Thu, 22 Apr 2004 14:50:21 -0400 Received: from [216.65.116.22] (helo=sm1255.hostcentric.net) by ietf-mx with esmtp (Exim 4.12) id 1BGjGi-00016j-00 for p2prg@ietf.org; Thu, 22 Apr 2004 14:49:52 -0400 Received: (qmail 30403 invoked by uid 107); 22 Apr 2004 18:31:20 -0000 Received: from c-66-41-30-194.mn.client2.attbi.com (HELO bitbucket) (justin@onionnetworks.com@66.41.30.194) by 216.65.116.22 with RC4-MD5 encrypted SMTP; 22 Apr 2004 18:31:20 -0000 From: Justin Chapweske To: discuss@jxta.org Cc: decentralization@yahoogroups.com, p2prg@ietf.org, p2prg@ietf.org In-Reply-To: <4087F52D.8020607@sun.com> References: <1082578771.4045.332.camel@bog> <40870FD9.40705@sun.com> <1082606019.8379.36.camel@bog> <1082614980.13116.135.camel@shall.internal.vwaty.com> <4087688B.4070308@sun.com> <1082643092.8379.56.camel@bog> <4087F52D.8020607@sun.com> Content-Type: text/plain Message-Id: <1082659634.8379.221.camel@bog> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 22 Apr 2004 13:47:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [P2Prg] Dynamic Networking Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have absolutely no problem with HTTP, being one of the "team of two > plus a > few" who released Tomcat to the world in '99. The problem I have with > the > HTTP application programming model is entirely in the realm of > deployment. > Server as largely assumed to be reachible via static addresses, IP. My > interests > are in "everything is a server, everthing is a client" such that > servers can > be instantiated, provissioned, and reclaimed dynamically w/ no harm > and in > fact "to great advantage" to the application network. In this model > the app > developer is literally constrained as to what the deployment network > looks > like. With JXTA, the app developer *owns* the network, can change it > as the > need arises, etc. BTW, this is the very epiphany I had that clued me > in that > there had to be a better way moving forward. I'm CC'ing this message to decentralization and p2p-hackers to engage the larger community on this interesting topic. James, I heartily agree with your goal of transcending the limitations of static addresses and allowing the network to be much more dynamic. However, I think we have different approaches for achieving this goal. My approach is to treat dynamic networking as a naming or URI problem. JXTA appears to take the approach that dynamic networking is a routing or messaging problem. Now, there are multiple levels at which one can solve dynamic networking from a naming perspective. The first level corresponds to solving the problem at the IP level using multicast and anycast addresses. A wonderful example of this is zeroconf/rendezvous. By allowing URIs/IP addresses to be resolved to any valid machine on the LAN, transparent dynamic networking is now enabled by any application that sits on top of IP and DNS. Of course, the limitation of dynamic networking at the IP level is that it only works for "anycast" type services where a number of nodes can provide the desired service. But, it does not provide for point-to-point dynamic networking services where a single specific node (possibly roaming) can provide the desired service. To solve the issue of contacting a single, possibly roaming, node with no reliable static IP address, we can look at the next layer up the naming stack - DNS. To solve dynamic networking at the DNS level, we make use of two different approaches: Akamai-style request routing via DNS, and dynamic DNS that routes to a single roaming node. The Akamai approach provides the anycast type functionality where a single name may resolve to any number of valid endpoints that can facilitate the desired service. The dynamic DNS approach allows a single roaming node to be contacted via a sturdy identifier where ever it may be. Now, the main limitations of the DNS approach is the reachability of nodes that are behind NAT/Firewalls and are unroutable via IP and the centralization of DNS infrastructure. The first issue can be solved by something like IPv6/Teredo or simply introducing public rendezvous points that proxy TCP streams to hidden nodes. This could be easily accomplished with SSH port forwarding. The second problem of centralization of DNS infrastructure is probably not an issue for most applications since all you need is a single static server to handle the DNS serving, and you can easily have a fully decentralized name space underneath your top level registered domain. Now, assuming that the NAT and centralization limitations of DNS are too limiting for your application, or you simply don't feel comfortable developing an application at the DNS level, the next layer in the naming stack is URIs. In order to provide dynamic networking at the URI naming level, you simply need to switch a portion of your URIs to non-DNS-based URIs. There is no need to switch all of your URIs to be location independent, and indeed in Swarmcast we freely mix static HTTP URIs with location independent UUID URIs. Location independent URIs, by their very nature, imply support for both an anycast model, as well as a single-end-node or point-to-point model. The only difference between these two cases is the number of authoritative sources that can provide the service associated with the URI in a secure fashion. In an anycast model, a number of nodes can authoritatively serve a URI, and in a point-to-point model, only a single end node can authoritatively serve a URI. Now, even though these location-independent URIs are not HTTP URIs, it doesn't mean that they can't still be served via HTTP. There are two ways to serve a non-HTTP URI via HTTP, the first is by proxying, and the second is by providing explicit URI resolution services. I'll skip over proxying for now and focus on URI resolution services. URI resolution services are very straight-forward. They are basically a mechanism to discover other equivalent URIs for a given URI. The goal of URI resolution in the context of dynamic networking is to resolve a location independent URI into one or more authoritative HTTP URIs. This concept is laid out in THTTP/RFC 2169 and the Content-Addressable Web (http://open-content.net/specs/draft-jchapweske-caw-03.html), though the latter is in severe need of updating/refinement. Under the covers, there are numerous ways that one can implement URI resolution, but I believe one should be careful to hide the details of the URI resolution specifics and allow developers to focus on simply naming and consuming resources. For example: o Gnutella provides a form of URI resolution by mapping keywords to URNs, then using THTTP to further resolve to specific HTTP end points. With magnet-URIs, people have done exactly that. o DHT's are an obvious candidate for URI resolution under the covers - I would love to see a DHT that provides a simple RFC 2169/THTTP interface for looking up URIs. o JXTA could also be used under the covers for URI resolution, using its security and group communication features as a value add. Once the URI is resolved, the end-user application would establish a direct connection to the resulting URI(s) to finish the transaction. Now, the last piece of this whole thing is HTTP proxying and caching. Now, even after mentioning earlier how DNS/HTTP-based URIs may have certain limitations, this all goes out the window when you consider HTTP caching semantics. HTTP defines very clear semantics for allowing a non-point-of-origin node to service a request directly and it can also fulfill requests for non-HTTP URIs. This allows fully dynamic URI-based networking to take place hidden completely behind the abstraction of an HTTP proxy. This approach also allows additional features like automatic-failover to be automatically added to applications w/o any modification to the original application My point behind this is that routing and messaging are not the answer to facilitating dynamic networking. An end application should not need to be concerned with how to route a message to a dynamic receiver, nor should it be concerned with protocols at a higher level than absolutely necessary - If you need dynamic networking on a LAN, use zeroconf. If you need dynamic networking among publicly addressable servers, use DNS. If you need dynamic networking to NAT'd nodes, then use URIs and HTTP. No matter which route you take, the code in the end-application is largely the same - it understands IP, DNS, and URIs. Imagine if Google required every client that connected with their service to participate in the proprietary Google query routing/messaging system. Of course, they chose to hide their service behind the abstraction of HTTP and their web services. In closing, JXTA has some great features, but end applications should be able to access JXTA services w/o knowing or caring that they are JXTA services. Peace, -Justin _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Sun Apr 25 14:19:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09917 for ; Sun, 25 Apr 2004 14:19:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHoAE-0007bt-PH for p2prg-archive@odin.ietf.org; Sun, 25 Apr 2004 14:15:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PIFcjD029253 for p2prg-archive@odin.ietf.org; Sun, 25 Apr 2004 14:15:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHo7r-0007DC-VS for p2prg-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 14:13:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09718 for ; Sun, 25 Apr 2004 14:13:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHo7p-0003GA-IY for p2prg-web-archive@ietf.org; Sun, 25 Apr 2004 14:13:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHo6r-00033X-00 for p2prg-web-archive@ietf.org; Sun, 25 Apr 2004 14:12:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHo68-0002rs-00 for p2prg-web-archive@ietf.org; Sun, 25 Apr 2004 14:11:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHo2q-0005bv-Gh; Sun, 25 Apr 2004 14:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHYte-0005L5-9Z for p2prg@optimus.ietf.org; Sat, 24 Apr 2004 21:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18524 for ; Sat, 24 Apr 2004 21:57:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHYtb-0007iA-53 for p2prg@ietf.org; Sat, 24 Apr 2004 21:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHYsf-0007Us-00 for p2prg@ietf.org; Sat, 24 Apr 2004 21:56:30 -0400 Received: from gw.activestate.com ([209.17.183.249] helo=smtp1.ActiveState.com) by ietf-mx with esmtp (Exim 4.12) id 1BHYs6-00074K-00 for p2prg@ietf.org; Sat, 24 Apr 2004 21:55:54 -0400 Received: from smtp3.ActiveState.com (latte.activestate.com [192.168.4.252]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id i3P1q73m021084; Sat, 24 Apr 2004 18:52:10 -0700 (envelope-from paul@prescod.net) Received: from prescod.net (ssh1.ActiveState.com [192.168.3.32]) by smtp3.ActiveState.com (8.12.9/8.12.9) with ESMTP id i3P1q6AD011831; Sat, 24 Apr 2004 18:52:07 -0700 Message-ID: <408B19C6.1070405@prescod.net> Date: Sat, 24 Apr 2004 18:52:06 -0700 From: Paul Prescod User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031008 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: decentralization@yahoogroups.com CC: discuss@jxta.org, p2prg@ietf.org References: <1082578771.4045.332.camel@bog> <40870FD9.40705@sun.com> <1082606019.8379.36.camel@bog> <1082614980.13116.135.camel@shall.internal.vwaty.com> <4087688B.4070308@sun.com> <1082643092.8379.56.camel@bog> <4087F52D.8020607@sun.com> <1082659634.8379.221.camel@bog> <20040423182418.GC20825@omnifarious.org> In-Reply-To: <20040423182418.GC20825@omnifarious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [P2Prg] Re: [decentralization] Dynamic Networking Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Thu, Apr 22, 2004 at 01:47:15PM -0500, Justin Chapweske wrote: > >>In order to provide dynamic networking at the URI naming level, you >>simply need to switch a portion of your URIs to non-DNS-based URIs. >>There is no need to switch all of your URIs to be location >>independent, and indeed in Swarmcast we freely mix static HTTP URIs >>with location independent UUID URIs. I can't believe that after all these years I am going to step back into the name versus location debate but I suppose I am just kind of nostalgic. Rather than write a long email I've written up a little essay. Please excuse the fact that it is barely edited: http://www.prescod.net/rest/combining_names_and_locations/ >>Location independent URIs, by their very nature, imply support for >>both an anycast model, as well as a single-end-node or point-to-point >>model. The only difference between these two cases is the number of >>authoritative sources that can provide the service associated with the >>URI in a secure fashion. In an anycast model, a number of nodes can >>authoritatively serve a URI, and in a point-to-point model, only a >>single end node can authoritatively serve a URI. These features all hold regardless of whether the URI has a syntax starting with "http://" or "uuid:" You can choose to use an anycast model for HTTP URIs, you can have multiple authoritiative sources for HTTP URIs (haven't you ever used Google's cache as more authoritiative than the referenced domain?) etc. Paul Prescod _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Mon Apr 26 05:27:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06724 for ; Mon, 26 Apr 2004 05:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2MU-0003Qo-G8 for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 05:25:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q9PExN013190 for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 05:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2HT-0002Nq-LH for p2prg-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 05:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06435 for ; Mon, 26 Apr 2004 05:19:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2HQ-0000JU-9F for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 05:20:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2GX-00005P-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 05:19:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI2Fe-0007eR-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 05:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2Af-0000h4-3c; Mon, 26 Apr 2004 05:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI25c-0007Fy-JD for p2prg@optimus.ietf.org; Mon, 26 Apr 2004 05:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05585 for ; Mon, 26 Apr 2004 05:07:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI25Z-0005B4-5o for p2prg@ietf.org; Mon, 26 Apr 2004 05:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI24b-0004yY-00 for p2prg@ietf.org; Mon, 26 Apr 2004 05:06:45 -0400 Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx with esmtp (Exim 4.12) id 1BI23c-0004m9-00 for p2prg@ietf.org; Mon, 26 Apr 2004 05:05:44 -0400 Received: from tu-ilmenau.de (saraswati.prakinf.tu-ilmenau.de [141.24.33.11]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i3Q95iNB004968 for ; Mon, 26 Apr 2004 11:05:44 +0200 (MEST) Message-ID: <408CD0E2.6080907@tu-ilmenau.de> Date: Mon, 26 Apr 2004 11:05:38 +0200 From: Thorsten Strufe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: p2prg References: <20040426020730.47597.qmail@web12401.mail.yahoo.com> <200404261044.31607.verdimar@comp.nus.edu.sg> In-Reply-To: <200404261044.31607.verdimar@comp.nus.edu.sg> X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [P2Prg] Re: [p2p-hackers] Models for distributed systems Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the hints! |>Correct me if I'm wrong, but I think the main |>difference is that, in c/s, any given node is either |>client or server, but in p2p a node can be both client |>and server at the same time... Well, if you consider the dynamic client/server model (client server with delegation) you get the same behaviour. Servers delegate subtasks to other servers, and hence become clients for a certain amount of time, in many c/s-systems. I suppose the difference is, that in P2P every node can be the originating source of a request, while in dynamic c/s the source is always a /client/. | But Thorsten asked more specific differences, and imho, | routing is one specific feature of P2P (file-sharing -- Gnutella/Kazza, | DHT, ad-hoc wireless network, etc.). I thought about this fact as well, but if that is the defining characteristic of P2P we had to call any routing system P2P, hadn't we? The problems solved in the system domain seem to be the same then. I've got as far as defining P2P as a system architecture (here comes the first question: does anybody know a good and formal definition of system architectures?). The system architecture can be best described with three different models. ~ * In the role model (formal definitions?): P2P knows of only one role, the servent. Every servent performs, or at least is able to perform the same tasks (symmetric roles), which usually consist of searching its local or locally registered ressources, forwarding search requests and serving an offered ressource. * In the interaction model (formal definitions?): Similar to the client/server model interaction in P2P architectures is done asynchronous via request-response message pairs. Any node can be the originating source for a request. * In the organisational model (fd?): No context knowledge other than a bootstrapping point to one occurence of a specific P2P system is needed to take part in it. There is no central naming system (anyway, it is possible to introduce an distributedly implemented algorithmic naming system as is done with Hashvalues in DHT-Systems). 'Pure' P2P systems are not structured at all (anyway, it again is possible to introduce a distributedly implemented structure as the supernodes in gnutella v0.6). Following this definition, a better word for P2P would probably be decentral distributed systems or collaborative systems (if this term wasn't already occupied by the cscw-world). I'm perfectly aware of the fact that this definition does not cover seti@home, napster and a fair share of other (file-sharing) systems, but it's still the best definition that I can come up with at the moment. And I would be highly interested in other views! :-) Thanks for comments in advance! thorsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAjNDiOQ9e8ojbqFYRAsiiAJ0dr6umtULNo4CiHiRMcCteQ1EhkQCdH+Tu 6Lzh7Nqq1x+CQ03eAn2FtGw= =hVIx -----END PGP SIGNATURE----- _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Mon Apr 26 12:08:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29461 for ; Mon, 26 Apr 2004 12:08:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8UI-00023r-UR for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 11:57:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFvg5c007917 for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 11:57:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8P4-0000ka-Rh for p2prg-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28528 for ; Mon, 26 Apr 2004 11:52:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8P3-0000PP-M2 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8O0-0000Kd-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:51:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI8Nf-0000Gy-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:50:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8F9-0006CZ-59; Mon, 26 Apr 2004 11:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI89D-0003ZE-HT for p2prg@optimus.ietf.org; Mon, 26 Apr 2004 11:35:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27536 for ; Mon, 26 Apr 2004 11:35:52 -0400 (EDT) From: raygao@comcast.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI89C-0006ul-HY for p2prg@ietf.org; Mon, 26 Apr 2004 11:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI88E-0006rT-00 for p2prg@ietf.org; Mon, 26 Apr 2004 11:34:55 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1BI87H-0006mW-00 for p2prg@ietf.org; Mon, 26 Apr 2004 11:33:55 -0400 Received: from 204.127.197.118 ([204.127.197.118]) by comcast.net (rwcrmhc12) with SMTP id <2004042615331901400icrnte>; Mon, 26 Apr 2004 15:33:19 +0000 Received: from [192.100.104.29] by 204.127.197.118; Mon, 26 Apr 2004 15:33:18 +0000 To: Thorsten Strufe Cc: p2prg Subject: Re: [P2Prg] Re: [p2p-hackers] Models for distributed systems Date: Mon, 26 Apr 2004 15:33:18 +0000 Message-Id: <042620041533.10799.408D2BBE000BF1C600002A2F2200750784FF909E98869E@comcast.net> X-Mailer: AT&T Message Center Version 1 (Apr 12 2004) X-Authenticated-Sender: cmF5Z2FvQGNvbWNhc3QubmV0 Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Thorsten, Regarding to P2P organization model, the primitive format is pure P2P without any structure or organization. However, in the process or optimizing the whole system. Stanley Milgram's six-degrees of separation becomes clearly evident. To demonstrate this, in Stanley M's original experiment of arbitrary asking people to contact a stockbroker in New York, following was found. Over 1/3 of the mail was channeled through one single individual and over 3/4 was routed by 3-4 key individuals. Likewise, for sake of building a robust P2P system for the mass, a set of directory servers or systems should be put in place. Such a system is not against the ad-hoc nature of P2P because even the rudimentary P2P networks needs to be overlaid on a IP-based system which evidently depends on h/w routers and switches. Similarly, in Gnutella 0.6, the "reflector" concept was introduced. Basically, a Gnutella reflector is equivalent to a JXTA proxy and rendezvous host. Ray Gao Editor-in-Chief, P2P Journal (http://p2pjournal.com) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for the hints! > > |>Correct me if I'm wrong, but I think the main > |>difference is that, in c/s, any given node is either > |>client or server, but in p2p a node can be both client > |>and server at the same time... > Well, if you consider the dynamic client/server model (client server > with delegation) you get the same behaviour. Servers delegate subtasks > to other servers, and hence become clients for a certain amount of time, > in many c/s-systems. > I suppose the difference is, that in P2P every node can be the > originating source of a request, while in dynamic c/s the source is > always a /client/. > > > | But Thorsten asked more specific differences, and imho, > | routing is one specific feature of P2P (file-sharing -- Gnutella/Kazza, > | DHT, ad-hoc wireless network, etc.). > I thought about this fact as well, but if that is the defining > characteristic of P2P we had to call any routing system P2P, hadn't we? > The problems solved in the system domain seem to be the same then. > > I've got as far as defining P2P as a system architecture (here comes the > first question: does anybody know a good and formal definition of system > architectures?). > The system architecture can be best described with three different models. > ~ * In the role model (formal definitions?): P2P knows of only one role, > the servent. Every servent performs, or at least is able to perform the > same tasks (symmetric roles), which usually consist of searching its > local or locally registered ressources, forwarding search requests and > serving an offered ressource. > * In the interaction model (formal definitions?): Similar to the > client/server model interaction in P2P architectures is done > asynchronous via request-response message pairs. Any node can be the > originating source for a request. > * In the organisational model (fd?): No context knowledge other than a > bootstrapping point to one occurence of a specific P2P system is needed > to take part in it. There is no central naming system (anyway, it is > possible to introduce an distributedly implemented algorithmic naming > system as is done with Hashvalues in DHT-Systems). 'Pure' P2P systems > are not structured at all (anyway, it again is possible to introduce a > distributedly implemented structure as the supernodes in gnutella v0.6). > > Following this definition, a better word for P2P would probably be > decentral distributed systems or collaborative systems (if this term > wasn't already occupied by the cscw-world). > > I'm perfectly aware of the fact that this definition does not cover > seti@home, napster and a fair share of other (file-sharing) systems, but > it's still the best definition that I can come up with at the moment. > And I would be highly interested in other views! :-) > > Thanks for comments in advance! > > thorsten > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAjNDiOQ9e8ojbqFYRAsiiAJ0dr6umtULNo4CiHiRMcCteQ1EhkQCdH+Tu > 6Lzh7Nqq1x+CQ03eAn2FtGw= > =hVIx > -----END PGP SIGNATURE----- > > _______________________________________________ > P2prg mailing list > P2prg@irtf.org > https://www.ietf.org/mailman/listinfo/p2prg _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Mon Apr 26 12:09:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29490 for ; Mon, 26 Apr 2004 12:09:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8WD-0002o3-DQ for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 11:59:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFxfK2010783 for p2prg-archive@odin.ietf.org; Mon, 26 Apr 2004 11:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8Q4-0000qz-FH for p2prg-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28591 for ; Mon, 26 Apr 2004 11:53:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8Q3-0000YX-Ag for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:53:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8PA-0000Qn-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:52:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI8OC-0000Kw-00 for p2prg-web-archive@ietf.org; Mon, 26 Apr 2004 11:51:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8F9-0006Cj-Fc; Mon, 26 Apr 2004 11:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI89I-0003cb-Ka for p2prg@optimus.ietf.org; Mon, 26 Apr 2004 11:36:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27555 for ; Mon, 26 Apr 2004 11:35:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI89H-0006vP-H1 for p2prg@ietf.org; Mon, 26 Apr 2004 11:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI88Q-0006tB-00 for p2prg@ietf.org; Mon, 26 Apr 2004 11:35:06 -0400 Received: from web50205.mail.yahoo.com ([206.190.38.46]) by ietf-mx with smtp (Exim 4.12) id 1BI87v-0006pa-00 for p2prg@ietf.org; Mon, 26 Apr 2004 11:34:35 -0400 Message-ID: <20040426153405.11213.qmail@web50205.mail.yahoo.com> Received: from [81.153.42.188] by web50205.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 16:34:05 BST Date: Mon, 26 Apr 2004 16:34:05 +0100 (BST) From: =?iso-8859-1?q?Michael=20Rogers?= Subject: Re: [P2Prg] Re: [p2p-hackers] Models for distributed systems To: Thorsten Strufe Cc: p2prg@ietf.org In-Reply-To: <408CD0E2.6080907@tu-ilmenau.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Thorsten, In my opinion P2P is a social rather than a technical category; the characteristic that distinguishes P2P systems from traditional distributed systems is autonomy. For example: Peer-to-peer system Traditional distributed system -------------------------------------------------------------------- Nodes may join and leave freely Participation is managed (although failures are expected) Each node has a different owner Number of owners is smaller than number of nodes (often there is only one owner) Any node may perform any role Roles are assigned (often there is only one role) Selfish behaviour should be Selfish behaviour is a bug or an expected attack -------------------------------------------------------------------- Autonomy may not be explicit in DHT designs - "nodes may join and leave freely" might be expressed as "the system must tolerate regular node joins and failures" - but in my opinion DHTs still fall into the P2P category because they can tolerate autonomy. The social characteristics of P2P lead to certain technical characteristics - for example, P2P works best with data that can be replicated (read-only files) or regenerated (SETI@home), because no single node can be relied on as an "authoritative source". Internet-based P2P works best when it doesn't rely on the DNS, because most potential participants have dynamic or NATed IP addresses (the largest pool of owners, if not the largest pool of machines). But these technical characteristics do not define P2P, they are just consequences of coping with autonomy. In a different environment (eg ad hoc wireless networks), the technical implications of autonomy may be different. Cheers, Michael ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Tue Apr 27 23:28:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20793 for ; Tue, 27 Apr 2004 23:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfgn-0002fq-0w for p2prg-archive@odin.ietf.org; Tue, 27 Apr 2004 23:24:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S3OmaF010278 for p2prg-archive@odin.ietf.org; Tue, 27 Apr 2004 23:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfbb-000288-Mt for p2prg-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 23:19:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20537 for ; Tue, 27 Apr 2004 23:19:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfbX-0002lf-Ou for p2prg-web-archive@ietf.org; Tue, 27 Apr 2004 23:19:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfaf-0002bk-00 for p2prg-web-archive@ietf.org; Tue, 27 Apr 2004 23:18:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIfZg-0002SQ-00 for p2prg-web-archive@ietf.org; Tue, 27 Apr 2004 23:17:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfVd-0001QP-Mw; Tue, 27 Apr 2004 23:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfSo-00019k-1y for p2prg@optimus.ietf.org; Tue, 27 Apr 2004 23:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19931 for ; Tue, 27 Apr 2004 23:10:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfSh-0001EP-LF for p2prg@ietf.org; Tue, 27 Apr 2004 23:10:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfQH-0000pW-00 for p2prg@ietf.org; Tue, 27 Apr 2004 23:07:46 -0400 Received: from web41206.mail.yahoo.com ([66.218.93.39]) by ietf-mx with smtp (Exim 4.12) id 1BIfPS-0000f8-00 for p2prg@ietf.org; Tue, 27 Apr 2004 23:06:54 -0400 Message-ID: <20040428030624.9095.qmail@web41206.mail.yahoo.com> Received: from [211.150.223.129] by web41206.mail.yahoo.com via HTTP; Wed, 28 Apr 2004 11:06:23 CST Date: Wed, 28 Apr 2004 11:06:23 +0800 (CST) From: =?gb2312?q?tang=20yan?= To: p2prg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA19932 Subject: [P2Prg] A question! Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have a stupid question. Why researchers study the overlay with directed graph? J. Xu, A. Kumar, and X. Yu, =A1=B0On the Fundamental Tradeoffs between Routing Table Size and Network Diameter in Peerto- Peer Networks,=A1=B1 To Appear in IEEE JSAC, Nov. 2003. Dmitri Loguinov, Anuj Kumar, Vivek Rai, Sai Ganesh. Graph-Theoretic Analysis of Structured Peer-to-Peer Systems: Routing Distances and Fault Resilience. The Moore bound of undirected graph is more better and the TCP connections can be treat as undirected. Can anyone give me some clues about it? Thanks very much! Best regards T.Y. _________________________________________________________ Do You Yahoo!?=20 =BB=DD=C6=D5TT=D3=CE=CF=B7=BE=E7=A3=AC=CD=E6=D3=CE=CF=B7=A3=AC=D6=D0=B4=F3= =BD=B1=A3=A1 http://cn.rd.yahoo.com/mail_cn/tag/SIG=3D1402c0to2/**http%3A%2F%2Fhp.ally= es.com%2Flaserjet%2Fgamestory%2Findex.html%3Fjumpid%3Dex_hphqapcn_Mongoos= eLJ1010%2F201073CN407016%2FYahoo _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg From exim@www1.ietf.org Fri Apr 30 09:17:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00077 for ; Fri, 30 Apr 2004 09:17:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXou-0006He-W1 for p2prg-archive@odin.ietf.org; Fri, 30 Apr 2004 09:12:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDCmif024148 for p2prg-archive@odin.ietf.org; Fri, 30 Apr 2004 09:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXnL-0005mi-Bx for p2prg-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:11:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29770 for ; Fri, 30 Apr 2004 09:11:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXnJ-0005P1-Qt for p2prg-web-archive@ietf.org; Fri, 30 Apr 2004 09:11:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXmP-0005Ed-00 for p2prg-web-archive@ietf.org; Fri, 30 Apr 2004 09:10:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXm0-000541-00 for p2prg-web-archive@ietf.org; Fri, 30 Apr 2004 09:09:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXYl-0001wL-5Q; Fri, 30 Apr 2004 08:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXWv-0001IK-4l for p2prg@optimus.ietf.org; Fri, 30 Apr 2004 08:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28193 for ; Fri, 30 Apr 2004 08:54:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXS1-0001Jf-9Y for p2prg@irtf.org; Fri, 30 Apr 2004 08:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXR0-00018I-00 for p2prg@irtf.org; Fri, 30 Apr 2004 08:48:06 -0400 Received: from dcn.ssu.ac.kr ([203.253.2.104]) by ietf-mx with esmtp (Exim 4.12) id 1BJXPx-0000iN-00 for p2prg@irtf.org; Fri, 30 Apr 2004 08:47:01 -0400 Received: from imonepc (dcnblue.ssu.ac.kr.3.253.203.in-addr.arpa [203.253.3.86] (may be forged)) by dcn.ssu.ac.kr (8.12.8/8.12.8) with ESMTP id i3UCjuxm026022 for ; Fri, 30 Apr 2004 21:45:56 +0900 Message-Id: <200404301245.i3UCjuxm026022@dcn.ssu.ac.kr> From: "Jae-yun, Jeong" To: Subject: [P2Prg] A question of guntella graphs Date: Fri, 30 Apr 2004 21:46:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQusScjD3aUudtYRICt72ColwkvnA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.25.0.2; VDF 6.25.0.39 Content-Transfer-Encoding: 7bit Sender: p2prg-admin@ietf.org Errors-To: p2prg-admin@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Peer-to-Peer Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all I am searching a document for using Gnutella connectivity graphs. The name of document is "Clip2 Gnutella crawl files". But, I can't find that...(any website, google, etc, ...) Can anyone help me? Please relate me URL or document file.. -- Jae-yun _______________________________________________ P2prg mailing list P2prg@irtf.org https://www.ietf.org/mailman/listinfo/p2prg