From p2prg-bounces@ietf.org Mon Jan 02 12:16:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTEH-00037w-5h; Mon, 02 Jan 2006 12:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTEE-00035h-Sl for p2prg@megatron.ietf.org; Mon, 02 Jan 2006 12:12:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21499 for ; Mon, 2 Jan 2006 12:11:01 -0500 (EST) Received: from zephyr.sfc.wide.ad.jp ([203.178.143.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtTIt-0006sY-MD for p2prg@ietf.org; Mon, 02 Jan 2006 12:17:32 -0500 Received: from [192.168.1.11] (60.91.150.220.ap.yournet.ne.jp [220.150.91.60]) (authenticated bits=0) by zephyr.sfc.wide.ad.jp (8.12.10/8.12.1) with ESMTP id k02HBKqg026136 for ; Tue, 3 Jan 2006 02:11:21 +0900 Mime-Version: 1.0 X-Sender: ks91@mail.sfc.wide.ad.jp X-Mailer: QUALCOMM MacOS X Eudora Version 6J Jr6 Message-Id: Date: Tue, 3 Jan 2006 02:11:17 +0900 To: p2prg@ietf.org From: Kenji Saito Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 2.0 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [P2Prg] Final CFP: DAS-P2P 2006 X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org I hope that all of you had a pleasant and happy new year. This is the final call for papers for DAS-P2P 2006. *** our apologies if you receive multiple copies of this e-mail *** *** the deadline for paper submission is January 8th (firm deadline) *** ****************************************************************************** * The First International Workshop on * Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) * http://das-p2p.wide.ad.jp/ * * In conjunction with The First International Conference on * Availability, Reliability and Security (ARES 2006). * http://www.ares-conf.org/ * * Vienna University of Technology, Austria * April 20th-22nd, 2006 ****************************************************************************** [CALL FOR PAPERS] The First International Workshop on Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) is the first workshop which focuses on dependability and sustainability of peer-to-peer (P2P) systems, with respect to their designs, operations, applications and social impacts. P2P can be a promising technology on which we can depend lives of ours and our children, upon which we can build sustainable societies. Designs of P2P systems are characterized by their usage of overlay networks such that there is symmetry in the roles among participants. This implies distribution of authorities, not only preventing introduction of single points of failure, but also assuring a level of autonomy which allows many of us to spontaneously start, maintain, or recover from failures of, such systems. Although difficulties exist, such as uncertainty in the trust among participants, one needs to be aware that such difficulties are, in many parts, due to our own human nature; depending on P2P is, in fact and literally, depending on ourselves and our friends, who seem to be the only ones we can trust anyway, when it comes to our own survival. The goal of this workshop is to share experiences, insights and new ideas, and set forth research agendas and suggestive future directions by collaborations among researchers with different disciplines and with similar interests toward dependability and sustainability. The following is a non-exhaustive list of relevant topics: * Designs and operations of dependable and sustainable P2P systems - Self-organization and emergence - Attack-resistance - Fault tolerance - Sustainable operations - Sustainable mutual trust - Sustainable reciprocal relationships * Applications and social impacts of dependable and sustainable P2P systems - Sustainable economy - Sustainable governance - Sustainable lifestyles - Rescue activities - Post-catastrophic recovery - Tackling environmental problems The program of the workshop will be a combination of invited talks, paper presentations and discussions. [SUBMISSION INSTRUCTIONS] (updated on 2005/10/21) The workshop invites your contributions of previously unpublished papers, which will be selected based on their originality, technical merit and topical relevance. Papers will also be selected by the likelihood that they will lead to interesting and fruitful discussions at the workshop. Your contributions should be formatted acoording to the IEEE Computer Society Press Proceedings Author Guidelines: 10-point Times, single-spaced, two-column format (see http://computer.org/cspress/instruct.htm for detail; if the link does not work, see http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm for approximation). Each of your contributions should not exceed 8 pages. See the workshop web site (http://das-p2p.wide.ad.jp/) for the submission procedure. [PUBLICATION] (updated on 2005/10/21) Proceedings of the workshop will be published by IEEE Computer Society Press. [IMPORTANT DATES] (updated on 2005/12/14) Paper submission due: January 8th, 2006 Notification of acceptance: January 18th, 2006 Camera-ready copies due: February 1st, 2006 Author registration due: February 1st, 2006 Workshop: April 20th-22nd, 2006 (exact date is to be decided) [REGISTRATION] Workshop registration will be handled by the ARES 2006 organization along with the main conference registration. [PROGRAM COMMITTEE] * Stephane Bressan, National University of Singapore, Singapore * Bernard Burg, Panasonic Research, USA * Ian Clarke, Freenet Project, UK * Roger Dingledine, The Free Haven Project, USA * Yusuke Doi, TOSHIBA Corporation, Japan (co-chair) * Claudiu Duma, Linkoping University, Sweden * Debojyoti Dutta, University of Southern California, USA * Noria Foukia, University of Otago, New Zealand * Maria Gini, University of Minnesota, USA * Achmad Nizar Hidayanto, University of Indonesia, Indonesia * Sam Joseph, University of Hawaii, USA * Youki Kadobayashi, Nara Instritute of Science and Technology, Japan (co-chair) * Anirban Mondal, University of Tokyo, Japan * Akiko Orita, Keio University, Japan * Omer F Rana, Cardiff University, UK * Kenji Saito, Keio University, Japan (co-chair) * Claudio Sartori, University of Bologna, Italy * Nguyen Manh Tho, Vienna University of Technology, Austria * Sheng Zhong, State University of New York at Buffalo, USA See the workshop web site (http://das-p2p.wide.ad.jp/) for any updates. ----- For further information, please contact program co-chair Kenji Saito, Graduate School of Media and Governance, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 Japan, e-mail: ks91@sfc.wide.ad.jp _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 03 15:21:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtsfA-00063W-A0; Tue, 03 Jan 2006 15:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etsf7-00063M-PJ for p2prg@megatron.ietf.org; Tue, 03 Jan 2006 15:21:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24103 for ; Tue, 3 Jan 2006 15:20:26 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtskO-0001zc-8I for p2prg@ietf.org; Tue, 03 Jan 2006 15:27:11 -0500 Received: from phys-d3-ha21sca-2 ([129.145.155.165]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k03KLTuh025197 for ; Tue, 3 Jan 2006 13:21:30 -0700 (MST) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ISJ00K019TCEZ@ha21sca-mail1.sfbay.sun.com> (original mail from Bernard.Traversat@Sun.COM) for p2prg@ietf.org; Tue, 03 Jan 2006 12:22:10 -0800 (PST) Received: from [192.18.191.136] (dhcp-usca21-191-136.red.iplanet.com [192.18.191.136]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ISJ00IW69WXX1@ha21sca-mail1.sfbay.sun.com> for p2prg@ietf.org; Tue, 03 Jan 2006 12:22:10 -0800 (PST) Date: Tue, 03 Jan 2006 12:21:22 -0800 From: Bernard Traversat To: p2prg@ietf.org Message-id: <43BADCC2.2010708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Subject: [P2Prg] New JXTA Java SE, Java ME and C/C++ releases are available! X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org The JXTA (www.jxta.org) community just announced the availability of three new releases of the JXTA P2P open-source protocols: - JXTA Java SE 2.3.6 "Jiggs Dinner" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=230) - JXTA Java ME 2.1.1 "Merimde" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=229) - JXTA-C/C++ 2.3 "Bali" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=231) These releases provide a number of bug fixes, performance improvements, and new enhanced features. These releases have been designed to be API and protocol backwards compatible with previous JXTA releases. All three implementations are fully interoperable. You can access these releases via the jxta.org download page: http://www.jxta.org/download.html Cheers and Happy New Year! B. --http://weblogs.java.net/blog/tra "As Java implies platform independence, and XML implies language independence, JXTA implies network independence." _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Fri Jan 13 17:26:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXNh-0007dj-PJ; Fri, 13 Jan 2006 17:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXNe-0007de-SW for p2prg@megatron.ietf.org; Fri, 13 Jan 2006 17:26:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16993 for ; Fri, 13 Jan 2006 17:25:23 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExXV2-0007v9-Q5 for p2prg@ietf.org; Fri, 13 Jan 2006 17:34:25 -0500 Received: from bufordw2 (dhcp237.Research.Panasonic.COM [150.169.1.237]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id k0DMQOKq022181 for ; Fri, 13 Jan 2006 17:26:24 -0500 From: "John Buford" To: Date: Fri, 13 Jan 2006 17:26:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0086_01C61866.7F9882B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Subject: [P2Prg] CORE subgroup problem statement X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C61866.7F9882B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A draft CORE subgroup problem statement is available (attached), also on the subgroup webpage: www.cs.uml.edu/~buford/irtf-p2prg/core.html Comments welcomed. John ------=_NextPart_000_0086_01C61866.7F9882B0 Content-Type: text/plain; name="draft-irtf-p2prg-core-problem-statement-00.txt" Content-Disposition: attachment; filename="draft-irtf-p2prg-core-problem-statement-00.txt" Content-Transfer-Encoding: quoted-printable IRTF P2PRG J. Buford=20 Internet Draft Panasonic=20 Expires: July 13, 2006 K. Ross=20 Polytechnic=20 M. Kolberg=20 Stirling=20 January 13, 2006=20 =20 =20 =20 CORE Subgroup Problem Statement=20 draft-irtf-p2prg-core-problem-statement-00.txt=20 Status of this Memo=20 By submitting this Internet-Draft, each author represents that =20 any applicable patent or other IPR claims of which he or she is = aware have been or will be disclosed, and any of which he or she = =20 becomes aware will be disclosed, in accordance with Section 6 of = =20 BCP 79.=20 This document may only be posted in an Internet-Draft.=20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 This Internet-Draft will expire on July 13,2006.=20 Copyright Notice=20 Copyright (C) The Internet Society (2006). All Rights Reserved.=20 =20 =20 =20 Buford Expires July 13, 2006 [Page 1]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 Abstract=20 New research in the design of peer-to-peer overlay networks offers=20 the possibility of addressing limitations of existing service,=20 resource and content discovery methods. We identify the research=20 goals to be pursued in investigating new designs for global scale=20 service discovery. The purpose of this document is to attract=20 participation from other researchers interested in these problems and = to lead to a coordinated research approach within the P2PRG CORE=20 subgroup.=20 Conventions used in this document=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119 [RFC2119].=20 Table of Contents=20 =20 1. Content, Resource and Service Discovery........................2=20 2. Definitions....................................................3=20 3. Problem Statement..............................................4=20 3.1. Global-Scale Service Discovery............................4=20 3.2. Service-Oriented Overlays.................................5=20 3.3. Internet Infrastructure...................................5=20 3.4. Content and Resource Discovery / Search...................5=20 4. Security Considerations........................................6=20 5. References.....................................................7=20 5.1. Normative References......................................7=20 5.2. Informative References....................................8=20 Author's Addresses...............................................10=20 Intellectual Property Statement..................................10=20 Disclaimer of Validity...........................................11=20 Copyright Statement..............................................11=20 Acknowledgment...................................................11=20 =20 1. Content, Resource and Service Discovery=20 Discovery of content, resources and services are fundamental=20 operations for peers in a peer-to-peer network. Many discovery=20 mechanisms have been proposed. However existing designs have=20 limitations in one or more areas of scalability, security,=20 interoperability, or generality. The purpose of this subgroup to=20 evaluate existing research, identify requirements, and develop=20 solutions for peer-to-peer content, resource, and service discovery=20 in wide-area networks. While content, resource, and service discovery = =20 =20 Buford Expires July 13, 2006 [Page 2]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 have been conventionally addressed by separate mechanisms, we are=20 interested in identifying unified mechanisms where possible. As a=20 minimum we are interested in global-scale service discovery.=20 Existing methods for service discovery include client-server=20 mechansisms (such as SLP [RFC2608][RFC2609]), mechanisms integrated=20 into device network adapters (such as Bluetooth SDP=20 [BLU2001][BLU2004] and Salutation [SAL1996]), mechanisms integrated=20 in middleware platforms (such as Web services [W3C2004A] [W3C2004B]=20 [W3C2004C], Jini [JINI2003A][JINI2003B], and JXTA [TRA2004]), and=20 home network oriented solutions (UPnP SSDP [UPNP2000]). =20 In addition there are experimental systems for service discovery such = as SSDS [CZE1999] and these extensions to SLP: WASRV [ROS1997], wide- area SLP [HUA2000], and mesh-enhanced SLP [RFC3528][ZHA2000]; and the = use of wide-area multicast to advertise and discover services=20 [MIC2004]. =20 Further there are various peer-to-peer overlay networks and proposed=20 designs, both unstructured and structured by which large numbers of=20 peers share content and services. Typically large-scale unstructured=20 peer-to-peer systems use limited scope flooding or random walk to=20 reach other peers with requests, whereas structured peer-to-peer=20 systems use a distributed hash table (DHT) to store key-value peers.=20 The integration of peer-to-peer overlay networks with service=20 definition and lookup has emerged as "service overlay" [GU2004]. An=20 example of mapping service definitions to a structured multi-hop=20 overlay is INS/Twine [BAL2002]. An example of using peer-to-peer=20 overlay for web services lookup is [SCH2004]. A related proposal is=20 [BRA2004].=20 Associated with various discovery mechanisms are related mechanisms=20 for service/resource advertisement, description, and invocation. =20 More extensive surveys of existing methods of service discovery=20 protocols include [BET2000][LEE2002][ZHU2002] and [TRA2004].=20 2. Definitions=20 Group: a collection of peers or groups of peers satisfying some=20 membership constraint=20 Search: a discovery mechanism in which content or resources stored in = a peer-to-peer network can be searched using various methods=20 including text search, keyword search, content-based retrieval or=20 meta-data search=20 Service: a computational function packaged for use by other nodes in=20 a networked environment=20 =20 =20 Buford Expires July 13, 2006 [Page 3]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 Service description: Information about a networked service such as=20 type of service, name of service, attributes of service, location of=20 service, invocation of service. May be stored in a document or at a=20 service repository or at the node offering the service; may be=20 broadcast or multicast by the node offering the service. May be=20 machine readable or human readable or both.=20 Service advertisement: the publication of a service description, in=20 whole or part, by or on behalf of the service offerer, for access by=20 other nodes=20 Service composition: the definition of a new service using two or=20 more existing services=20 Service discovery: retrieval or access of a service description by=20 nodes other than the service offerer, including browsing, search by=20 name, class, type and or service attributes=20 Service invocation: remote execution of a service over a computer=20 network=20 Service notification: an event signaling change in the availability=20 or state of a service=20 Service overlay: the use of an overlay network to store and lookup=20 service descriptions=20 3. Problem Statement=20 3.1. Global-Scale Service Discovery=20 A global-scale service discovery mechanism should provide the=20 following capabilities:=20 o Internet-wide service advertisement and discovery of services,=20 such that any service on the Internet can be discovered by any=20 peer on the Internet. The expected volume of transactions=20 expected in a global service discovery mechanism is in the range=20 of DNS lookup volume.=20 o Ability to index service descriptions by geographic location and=20 domain in which the services are available=20 o Ability to index service descriptions by arbitrary meta data=20 regarding the service=20 o Support for creating and using composite services from services=20 offered by different peers=20 =20 =20 Buford Expires July 13, 2006 [Page 4]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 o Use of multiple service description formats which might be=20 tailored by application or level of semantic description=20 o Access to services, service descriptions, and service=20 advertisements dependent on authorization rights=20 o Access to services, service descriptions, and service=20 advertisements by peer group membership=20 o Individual domains can administer the service availability,=20 security, and service descriptions=20 In addition it is desirable that:=20 o The mechanism can be used in isolation by peers in PANs, ad hoc=20 networks, or other limited networking environments=20 o Collections of peers can join and separate from other collections=20 of peers without interruption a service discovery capability=20 within the respective collections=20 o The mechanism is compatible with existing service discovery=20 mechanisms, possibly through gateways=20 3.2. Service-Oriented Overlays=20 o The mechanism is open with respect to the overlay network, and=20 should work with multiple distinct overlay networks=20 o Different overlays supporting service discovery will vary by=20 architecture, security, and performance characteristics=20 3.3. Internet Infrastructure=20 o The mechanism may be used for portions Internet infrastructure=20 services such as DNS [COX2002].=20 o The mechanism does not require changing existing Internet=20 infrastructure=20 3.4. Content and Resource Discovery / Search=20 o The mechanism for service discovery may be useful for content and=20 resource discovery, and a unified design is desirable=20 o Indexing, mapping, and lookup for specific discovery types in the=20 overlay may vary=20 =20 =20 Buford Expires July 13, 2006 [Page 5]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 4. Security Considerations=20 There are no new security considerations in this document.=20 =20 =20 =20 Buford Expires July 13, 2006 [Page 6]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 5. References=20 5.1. Normative References=20 [BLU2004] Bluetooth Specification version 2. Vol. 3 Core System=20 Package. Part B Service Discovery Protocol (SDP).=20 [BLU2001] Bluetooth Specification version 1.1. Service Discovery=20 Application Profile. Part K:2. Feb 22, 2001. =20 [IANASLP] IANA service location templates.=20 http://www.iana.org/assignments/svrloc-templates/=20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for=20 Syntax Specifications: ABNF", RFC 2234, Internet Mail=20 Consortium and Demon Internet Ltd., November 1997.=20 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. Service=20 Location Protocol, Version 2. IETF RFC 2608. June 1999.=20 [RFC2609] E. Guttman, C. Perkins, J. Kempf. Service Templates and=20 Service: Schemes. IETF RFC 2609. June 1999.=20 [RFC3528] W. Zhao, H. Schulzrinne. Mesh-enhanced Service Location=20 Protocol (mSLP). IETF RFC 3528. April 2003. =20 [UPN2000] UPnP Forum. UPnP Device Architecture. Version 1. June 8, = 2000. =20 [W3C2004a]W3C. Web Services Architecture. =20 http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Feb 11,=20 2004.=20 [W3C2004b]W3C. Web Services Description Language version 2.0 Part=20 1: Core Language. http://www.w3.org/TR/wsdl20 Aug 3, 2004.=20 [W3C2004c]W3C. Web Services Description Language (WSDL) Version 2.0. = Part 3: Bindings. http://www.w3.org/TR/wsdl20-bindings Aug = 3, 2004.=20 =20 =20 Buford Expires July 13, 2006 [Page 7]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 5.2. Informative References=20 [BAL2002] M. Balazinska, H. Balakrishnan, and D. Karger. INS/Twine: A = Scalable Peer-to-Peer Architecture for Intentional Resource = Discovery. In Proceedings of Pervasive 2002. =20 [BAR1999] M. Barbeau. Service discovery in a mobile agent API using=20 SLP, Global Telecommunications Conference (GLOBECOM '99),=20 1999, 391-395 vol. 1a =20 [BET2000] C. Bettstetter, C. Renner. A Comparison of Service=20 Discovery Protocols and Implementation of the Service=20 Location Protocol, In proceeding of Open European Summer=20 School (EUNICE), Twente Netherlands, September 13-15, 2000. = =20 [BRA2004] William B. Bradley, David P. Maher. The NEMO P2P Service=20 Orchestration Framework. Proceedings of the 37th Hawaii=20 International Conference on System Sciences - 2004=20 [COL2003] Mesh-Enhanced SLP Project at Columbia Univ:=20 http://www1.cs.columbia.edu/~zwb/project/slp/ =20 [COX2002] R. Cox, A. Muthitacharoen, and R. T. Morris, Serving DNS=20 using a Peer-to-Peer Lookup Service, IPTPS, Mar. 2002=20 [CZE1999] Czerwinski, S. E., et al. 1999. An architecture for a=20 secure service discovery service. In Proceedings of the 5th = Annual ACM/IEEE international Conference on Mobile=20 Computing and Networking (Seattle, Washington, United=20 States, August 15 - 19, 1999). MobiCom '99. ACM Press, New=20 York, NY, 24-35=20 [FRE2004] Freudenthal, E. and Karamcheti, V. 2004. DisCo: Middleware=20 for Securely Deploying Decomposable Services in Partly=20 Trusted Environments. In Proceedings of the 24th=20 international Conference on Distributed Computing Systems=20 (Icdcs'04) (March 24 - 26, 2004). ICDCS. IEEE Computer=20 Society, Washington, DC, 494-503. [GOT2002] K. Gottschalk,=20 S. Graham, H. Kreger, J. Snell. Introduction to Web=20 Service Architecture. IBM Systems J. v 41 n 2. 2002. =20 [GU2004] Gu, X., Nahrstedt, K., and Yu, B. 2004. SpiderNet: An=20 Integrated Peer-to-Peer Service Composition Framework. In=20 Proceedings of the 13th IEEE international Symposium on=20 High Performance Distributed Computing (Hpdc'04) - Volume=20 00 (June 04 - 06, 2004). HPDC. IEEE Computer Society,=20 Washington, DC, 110-119. =20 =20 =20 Buford Expires July 13, 2006 [Page 8]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 [HUA2000] An-Cheng Huang and Peter Steenkiste. A Flexible=20 Architecture for Wide-Area Service Discovery,. The Third=20 IEEE Conference on Open Architectures and Network=20 Programming (OPENARCH 2000), March 26-27, 2000. =20 [JIN2003a] Sun Microsystems. Jini Architecture Specification v 2. =20 June 2003. =20 [JIN2003b] Sun Microsystems. Jini=99 Technology Core Platform=20 Specification. June 2003.=20 [LEE2002] C. Lee and S. Helal. Protocols for Service Discovery in=20 Dynamic and Mobile Networks. Intl. J. of Computer=20 Research. v. 11 n 1 pp. 1-12. 2002.=20 [MIC2004] Microsoft. Web Services Dynamic Discovery (WS-Discovery). = Oct 2004.=20 [RAM2002] Raman, B., et al. 2002. The SAHARA Model for Service=20 Composition across Multiple Providers. In Proceedings of=20 the First international Conference on Pervasive Computing=20 (August 26 - 28, 2002). F. Mattern and M. Naghshineh, Eds.=20 Lecture Notes In Computer Science, vol. 2414. Springer- Verlag, London, 1-14.=20 [ROS1997] J.Rosenberg, H.Schulzrinne, B.Suter. Wide Area Network=20 Service Location. IETF draft-ietf-svrloc-wasrv-01.txt.=20 Work in progress. Nov 14, 1997. =20 [SAL1996] Salutation Consortium. Salutation Architecture=20 Specification (part 1) Version 2.0c. www.salutation.org =20 [SCH2004] C. Schmidt and M. Parashar, A Peer-to-Peer Approach to Web=20 Service Discovery, World Wide Web Journal, Vol. 7, Issue 2, = June 2004=20 [STE1998] M. v. Steen, F. J. Hauck, P. Homburg, and A. S. Tanenbaum,=20 Locating Objects in Wide-Area Systems, IEEE Communications=20 Magazine, January, 1998, pp. 104-109 =20 [TRA2004] Bernard Traversat, Ahkil Arora, Mohamed Abdelaziz, Mike=20 Duigou, Carl Haywood, Jean-Christophe Hugly, Eric Pouyoul,=20 Bill Yeager. Project JXTA 2.0 Super-Peer Virtual Network.=20 www.jxta.org=20 =20 =20 Buford Expires July 13, 2006 [Page 9]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 [ZHA2000] Weibin Zhao, Henning Schulzrinne, and Erik Guttman, "mSLP - = Mesh-enhanced Service Location Protocol", in International=20 Conference on Computer Communication and Network, Las=20 Vegas, Nevada, October 2000.=20 [ZHU2002] F. Zhu, M. Mutka, L. Ni. Classification of Service=20 Discovery in Pervasive Computing Environments. MSU-CSE-02- 24, Michigan State University, EastLansing, 2002.=20 Author's Addresses=20 John Buford=20 Panasonic Digital Networking Lab=20 2 Research Way, 3rd Floor=20 Princeton, NJ 08540=20 Email: buford@research.panasonic.com=20 =20 Keith Ross=20 Department of Computer and Information Science =20 Polytechnic University =20 Six MetroTech Center =20 Brooklyn, NY 11201=20 Email: ross@poly.edu=20 =20 Mario Kolberg=20 Room 4B60, Cottrell Building =20 Department of Computing Science and Mathematics =20 University of Stirling =20 Stirling FK9 4LA =20 Scotland=20 Email: mkolberg@ieee.org=20 Intellectual Property Statement=20 The IETF takes no position regarding the validity or scope of any=20 Intellectual Property Rights or other rights that might be claimed to = pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; nor does it represent that it has=20 made any independent effort to identify any such rights. Information = on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of = such proprietary rights by implementers or users of this=20 =20 =20 Buford Expires July 13, 2006 [Page 10]=20 =0C Internet-Draft P2PRG CORE Subgroup Problem Statement January 2006=20 =20 specification can be obtained from the IETF on-line IPR repository at = http://www.ietf.org/ipr.=20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at=20 ietf-ipr@ietf.org=20 Disclaimer of Validity=20 This document and the information contained herein are provided on an = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS = OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 Copyright Statement=20 Copyright (C) The Internet Society (2006).=20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 Acknowledgment=20 Funding for the RFC Editor function is currently provided by the=20 Internet Society.=20 =20 =20 =20 Buford Expires July 13, 2006 [Page 11]=20 =0C ------=_NextPart_000_0086_01C61866.7F9882B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg ------=_NextPart_000_0086_01C61866.7F9882B0-- From p2prg-bounces@ietf.org Mon Jan 16 09:06:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUzh-0006Z2-97; Mon, 16 Jan 2006 09:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUzf-0006Yb-G8 for p2prg@megatron.ietf.org; Mon, 16 Jan 2006 09:05:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15189 for ; Mon, 16 Jan 2006 09:04:34 -0500 (EST) Received: from brunello.labnet.cnit.it ([217.9.74.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyV7Z-0002R7-5H for p2prg@ietf.org; Mon, 16 Jan 2006 09:14:11 -0500 Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it (Postfix) with ESMTP id E80164E5C8; Mon, 16 Jan 2006 15:05:22 +0100 (CET) Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03591-01-26; Mon, 16 Jan 2006 15:05:00 +0100 (CET) Received: from novello.labnet.cnit.it (ns.cnit.it [217.9.64.3]) by brunello.labnet.cnit.it (Postfix) with ESMTP id CF1A84E83D; Mon, 16 Jan 2006 15:05:00 +0100 (CET) Received: from [130.251.11.101] (dhcp1.com.dist.unige.it [130.251.11.101]) by novello.labnet.cnit.it (Postfix) with ESMTP id 164183CED9; Mon, 16 Jan 2006 15:04:59 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Luca Caviglione Subject: Re: [P2Prg] CORE subgroup problem statement Date: Mon, 16 Jan 2006 15:05:39 +0100 To: John Buford X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Dear John, I found the draft interesting. Please, find in this mail same comments. I am reporting part of the text and inserting my ideas between the tags. Best Regards, Luca Pag. 1: However existing designs have limitations in one or more areas of scalability, security, interoperability, or generality. I am not quite sure there are generality problems. At least, the concept of generality should be defined. What I think is valuable of p2p, is its ability of building overlays, and then allowing some kind of network independency (BTW, citing JXTA is something, that recalls this concept). Then, you should clarify what is generality for you and why you think p2p can change something. Is generality something related to "re-usability" or a more "smart" concept, such as the network independent deisgn? . Pag 2: The presented literature is quite comprehensive. However, I would consider as follows. Since we are talking about IETF, you can cite some good technologies, which are something related to service discovery. Mostly, they are suitable for local-small scale scenarios, but someone is thinking about enabling them for the global Internet. For instance: o) RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt o) The DNSService Discovery (http://www.dns-sd.org/). Besides, the DNS service discovery can be jointly used with the Multicast DNS (http://www.multicastdns.org/ and http://files.dns-sd.org/draft- cheshire-dnsext-nbp.txt). And of course, even if "human readable" and "rough", the DNS is related to "overlays". (http://files.dns-sd.org/ draft-cheshire-dnsext-dns-sd.txt) o) You can cite also Zeroconf (http://www.zeroconf.org/). o) And of course, one can exploit some mapping with underlying technologies, such as IPv6. Further there are various peer-to-peer overlay networks and proposed designs, both unstructured and structured by which large numbers of peers share content and services. From a strict p2p point of view, there are also hybrid architectural flavors, such as BitTorrent. In hybrid frameworks, the centralized component plays a role (not being solely devoted to bootstrap). You know, people out there have used client-server for decades, hence I would be a little pragmatic. Typically large-scale unstructured peer-to-peer systems use limited scope flooding or random walk to reach other peers with requests... In hybrid systems, centralized component are used to locate peers and then directly route requests. For instance, in eMule (I am citing file-sharing since is quite popular), you can use 3 different architectural flavors: 1) use server to locate via e2DK 2) use Kad (XOR-based Chord DHT ring) 3) Exchange info via hording. Or in OpenNap 1)Use a OpenNap Server 2)Use a chained facility of OpenNap servers to route requests. However, the basic under such remarks is that "the more the unstructured p2p system is large, the worse the limited scope flooding performs". For this reason, supernodes, centralized components and so on have been introduced. Lastly, since it is a problem statement draft, I would mention that "limited scope flooding" does not allow to perform _exhaustive_ searches. Then we have to be honest: p2p is great for what you propose, but still need to be fixed. And in a problem statement draft, probably will be a nicer phrase. "Are you going to migrate DNS to an architecture that could be unable to resolve some URL, because peers responsible are too distant?" Search: a discovery mechanism in which content or resources stored in a peer-to-peer network can be searched using various methods including text search, keyword search, content-based retrieval or meta-data search Are they stored in the p2p network? Or are they stored in peers? My 2 cents: -)how the overlay is "built" states intrinsically _how to retrieve_ (e.g., A DNS based Overlay roughly corresponds to text search). -)peers belonging to a given overlay _store_ the content or resources. (??? I am not fond of CDN, but CDN-literature should be inspiring) Service: a computational function packaged for use by other nodes in a networked environment . It sounds like "RPCs" or "Stored Procedure" stuff. It is quite clear the idea, but for my personal style I would avoid "computational"... "a portion of peer resource" is more general (maybe when you'll define your architectures, you'll have storage-peers, computing- peers... hence, it is more general). Pag 3: Service description: Information about a networked service such as type of service, name of service, attributes of service, location of service, invocation of service. May be stored in a document or at a service repository Confusion here (for me, it is not enough clear). I can't convince myself about what a "Service Repository" is: o) Service Repository: a peer containing related infos. o) Service Repository: a boot strap server which allows to locate and exploit a p2p-based service. o) A portion of the overlay. o) A centralized component (see previous comment). But basically: "Is Service Repository, inside or outside the p2p- framework?" The expected volume of transactions expected in a global service discovery mechanism is in the range of DNS lookup volume. How can justify such bound? "The expected volume of transactions expected in a global service discovery mechanism is in the range of DNS lookup volume." Pag. 4 Use of multiple service description formats which might be tailored by application or level of semantic description I appreciate this point, really. Access to services, service descriptions, and service advertisements dependent on authorization rights I can see HIP at the horizon... The mechanism can be used in isolation by peers in PANs, ad hoc networks, or other limited networking environments Not clear what isolation is... Pag. 5 There are no new security considerations in this document. I agree. In this incarnation the security considerations are not pertinent. Il giorno 13/gen/06, alle ore 23:26, John Buford ha scritto: > > A draft CORE subgroup problem statement > is available (attached), also on the > subgroup webpage: > > www.cs.uml.edu/~buford/irtf-p2prg/core.html > > Comments welcomed. > > John > > _______________________________________________ > P2prg mailing list > P2prg@irtf.org > https://www1.ietf.org/mailman/listinfo/p2prg _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Mon Jan 16 10:49:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyWbn-0003Jw-2k; Mon, 16 Jan 2006 10:49:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyWbl-0003HR-6S for p2prg@megatron.ietf.org; Mon, 16 Jan 2006 10:49:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22138 for ; Mon, 16 Jan 2006 10:47:58 -0500 (EST) From: shudo@computer.org Received: from mx1.aist.go.jp ([150.29.246.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyWje-0007Lm-Io for p2prg@ietf.org; Mon, 16 Jan 2006 10:57:35 -0500 Received: from rpsmtp1.aist.go.jp (rpsmtp1.aist.go.jp [150.29.254.30] (may be forged)) by mx1.aist.go.jp with ESMTP id k0GFnJBI005608 for ; Tue, 17 Jan 2006 00:49:19 +0900 (JST) env-from (shudo@computer.org) Received: from smtp3.aist.go.jp by rpsmtp1.aist.go.jp with ESMTP id k0GFnIV3004288 for ; Tue, 17 Jan 2006 00:49:18 +0900 (JST) env-from (shudo@computer.org) Received: by smtp3.aist.go.jp with ESMTP id k0GFnHud004637 for ; Tue, 17 Jan 2006 00:49:18 +0900 (JST) env-from (shudo@computer.org) Date: Tue, 17 Jan 2006 00:28:54 +0900 (JST) Message-Id: <20060117.002854.497717774.shudo@aist.go.jp> To: p2prg@ietf.org X-Mailer: Mew version 4.2 on XEmacs 21.4.18 (Social Property) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [P2Prg] Overlay Weaver: An Overlay Construction Toolkit X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org I'm pleased to announce the initial release of Overlay Weaver. Overlay Weaver: An Overlay Construction Toolkit http://overlayweaver.sf.net/ It supports overlay algorithm designers in addition to application developers. For application developers, the toolkit provides a common API for higher-level services such as distributed hashtable (DHT) and multicast. Applications relying on the common API depend no specific transport protocol, database implementation and routing algorithm. The toolkit provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. These algorithms could be implemented only in hundreds lines of code because of routing layer decomposition. Routing layer under the higher-level services has been decomposed into multiple components, routing driver, routing algorithm and messaging service. The decomposition also facilitates implementation of a new algorithm. A newly implemented algorithm can be tested, evaluated and compared on emulator, which can host thousands of virtual nodes It enables large-scale emulation and fair comparison between algorithms. Features: - Implemented in Java 5. (except part of IPv4 multicast router which is in C.) - Provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. - Two routing drivers respectively performing iterative and recursive routing work with all routing algorithm (except recursive routing with Kademlia). - Provides a distributed environment emulator. It has demonstrated that it can host 4000 (virtual) nodes on a single 32 bit computer with 1 GB memory. - There are multiple implementations of communication layer, with UDP, TCP and emulated messaging layer. Note that the UDP implementation does UDP hole punching. - A visualization tool, Messaging Visualizer provided. It shows nodes and communications just in time and works both on the emulator and a real network. There are screenshots and a demonstration provided on the web site. Please take a look. We have written a paper but now it's in Japanese. I will prepare an English paper in few months. We'd appreciate activities utilizing this toolkit such as application development, algorithm researches, testbed construction and operation. We'll support them. Please contact us or subscribe a mailing list. Thanks, Kazuyuki Shudo, Ph.D. shudo@ni.aist.go.jp, http://www.shudo.net/ Grid Technology Research Center National Institute of Advanced Industrial Science and Technology (AIST) _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 17 12:37:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyulx-0001mL-3N; Tue, 17 Jan 2006 12:37:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyulv-0001ly-DA for p2prg@megatron.ietf.org; Tue, 17 Jan 2006 12:37:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03407 for ; Tue, 17 Jan 2006 12:36:06 -0500 (EST) Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyuu4-000066-IU for p2prg@ietf.org; Tue, 17 Jan 2006 12:45:57 -0500 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id A21B9D2FE72; Tue, 17 Jan 2006 12:36:52 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 17 Jan 2006 12:36:52 -0500 X-Sasl-enc: Z23TD5soCWpeP72yKv/Vt0cpZhjQ4I1TJcxuHgeFtdQ3 1137519411 Received: from [192.168.0.3] (adsl-70-231-230-125.dsl.snfc21.sbcglobal.net [70.231.230.125]) by frontend2.messagingengine.com (Postfix) with ESMTP id 820F4571FB0; Tue, 17 Jan 2006 12:36:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D114E1C-BB3C-42CB-BEEB-1EB6BCC82977@fastmail.fm> Content-Transfer-Encoding: 7bit From: Bill Yeager Date: Tue, 17 Jan 2006 09:36:46 -0800 To: p2prg@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Samrat Bhattacharjee Subject: [P2Prg] 65th IETF X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org As many of you are aware, the 65th IETF meeting will be held in Dallas, Texas from March 19th to March 24th. We plan on having a RG meeting, and so far only John Buford has expressed interest in presenting his CORE results. Are there any others of you that would like to present research results or proposals? Once we've an idea of how much time we will need we will apply for a time slot that attempts to minimize conflicts with WG activities. The cut-off date for requesting a session is Monday, February 13 at 17:00 ET (22:00 GMT). But, we'd like to do this as soon as possible. Thanks, Bill _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 02:00:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IAX-000245-Ca; Tue, 24 Jan 2006 02:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IAU-000240-Sx for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 02:00:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13912 for ; Tue, 24 Jan 2006 01:59:12 -0500 (EST) From: buford@research.panasonic.com Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1IJx-0004w9-NI for p2prg@ietf.org; Tue, 24 Jan 2006 02:10:32 -0500 Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k0O70H4K005018; Tue, 24 Jan 2006 02:00:17 -0500 Received: from localhost (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with SMTP id 67AFF1E834F; Tue, 24 Jan 2006 01:48:58 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62])by redwood.research.panasonic.com (Postfix) with ESMTP id 16D731E834F; Tue, 24 Jan 2006 01:48:49 -0500 (EST) Received: from [68.44.52.109] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Tue, 24 Jan 2006 02:00:08 -0500 To: p2prg@ietf.org, luca.caviglione@cnit.it Message-ID: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> Date: Tue, 24 Jan 2006 02:00:08 -0500 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2Prg] CORE subgroup problem statement X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:69.69242 C:3 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Dear Luca, Thanks very much for the detailed and useful comments. Responses below. Best regards, John > Dear John, > I found the draft interesting. Please, find in this mail same comments. > I am reporting part of the text and inserting my ideas between the tags. > > > Best Regards, > Luca > > > Pag. 1: > > However existing designs have limitations in one or more areas of scalability, security, interoperability, or generality. > > > I am not quite sure there are generality problems. At least, the concept of generality should be defined. What I think is valuable of p2p, is its ability of building overlays, and then allowing some kind of network independency (BTW, citing JXTA is something, that recalls this concept). Then, you should clarify what is generality for you and why you think p2p can change something. Is generality something related to "re-usability" or a more "smart" concept, such as the network independent deisgn? > . Yes, I agree that p2p overlay and index mechanisms are quite general. But some p2p systems are application-specific (e.g., file sharing, voip) so not being general-purpose is meant from service-offering standpoint. So generality has to do, in my opinion, with supporting any type of service. > > > Pag 2: > > The presented literature is quite comprehensive. However, I would consider as follows. > > > Since we are talking about IETF, you can cite some good technologies, which are something related to service discovery. Mostly, they are suitable for local-small scale scenarios, but someone is thinking about enabling them for the global Internet. For instance: > > o) RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt > > o) The DNSService Discovery (http://www.dns-sd.org/). Besides, the DNS service discovery can be jointly used with the Multicast DNS (http://www.multicastdns.org/ and http://files.dns-sd.org/draft- cheshire-dnsext-nbp.txt). And of course, even if "human readable" and "rough", the DNS is related to "overlays". (http://files.dns-sd.org/ draft-cheshire-dnsext-dns-sd.txt) > > > o) You can cite also Zeroconf (http://www.zeroconf.org/). > > o) And of course, one can exploit some mapping with underlying technologies, such as IPv6. > Yes, thanks for these suggestions. Definitely RFC2782 and multicastdns and zeroconf. However isn't IPv6 an enabling technology? > > Further there are various peer-to-peer overlay networks and proposed designs, both unstructured and structured by which large numbers of peers share content and services. > > > From a strict p2p point of view, there are also hybrid architectural flavors, such as BitTorrent. In hybrid frameworks, the centralized component plays a role (not being solely devoted to bootstrap). You know, people out there have used client-server for decades, hence I would be a little pragmatic. > Yes agree. In fact the P2P overlay survey we posted had hybrid in the taxonomy. Good point. > > Typically large-scale unstructured peer-to-peer systems use limited scope flooding or random walk to reach other peers with requests... > > > In hybrid systems, centralized component are used to locate peers and then directly route requests. > > For instance, in eMule (I am citing file-sharing since is quite popular), you can use 3 different architectural flavors: > 1) use server to locate via e2DK > 2) use Kad (XOR-based Chord DHT ring) > 3) Exchange info via hording. > > > Or in OpenNap > 1)Use a OpenNap Server > 2)Use a chained facility of OpenNap servers to route requests. > > However, the basic under such remarks is that "the more the unstructured p2p system is large, the worse the limited scope flooding performs". For this reason, supernodes, centralized components and so on have been introduced. > > Lastly, since it is a problem statement draft, I would mention that "limited scope flooding" does not allow to perform _exhaustive_ searches. Then we have to be honest: p2p is great for what you propose, but still need to be fixed. And in a problem statement draft, probably will be a nicer phrase. > > "Are you going to migrate DNS to an architecture that could be unable to resolve some URL, because peers responsible are too distant?" > Good points, this can be cited, do you suggest citations for eMule and OpenNap technical details? Also, we kept the overlay discussion short in the problem statement since we have proposed in the charter to prepare a separate survey document. So some of this discussion might go there. Regarding the chance of not finding something that is stored somewhere in the overlay, yes it doesn't seem like a desirable scenario. What would be nice from a research standpoint is to have a probabilistic formula as a function of size, architecture, churn, average node lifetime, replication rate, and index pollution, etc. of finding an item stored in the overlay. > > Search: a discovery mechanism in which content or resources stored in a peer-to-peer network can be searched using various methods including text search, keyword search, content-based retrieval or meta-data search > > > > Are they stored in the p2p network? Or are they stored in peers? > > > My 2 cents: > > -)how the overlay is "built" states intrinsically _how to retrieve_ (e.g., A DNS based Overlay roughly corresponds to text search). > > > -)peers belonging to a given overlay _store_ the content or resources. > > > (??? I am not fond of CDN, but CDN-literature should be inspiring) > Why is the distinction between storage in the peer vs p2p network important? Consider a system like OpenDHT where some node which is not part of the p2p system can insert and lookup into a p2p index formed by another set of nodes. from the client node standpoint, the p2p index could just as well be a single server, and the storage is somewhere in the collection of nodes, hence "p2p network". Also there is the case of replicated entries, and cases where we might split up an object into parts before indexing each part. Regarding "how the overlay is built ... how to retrieve". I am not sure. A number of proposals develop complex mappings and lookups on to a simple hash-base index. Agree that CDN is relevant. Seems like a lot of CDN is push-oriented model anticipating future requests. > > Service: a computational function packaged for use by other nodes in a networked environment . > > > It sounds like "RPCs" or "Stored Procedure" stuff. It is quite clear the idea, but for my personal style I would avoid "computational"... "a portion of peer resource" is more general (maybe when you'll define your architectures, you'll have storage-peers, computing- peers... hence, it is more general). > How about: Service: an interface to a resource packaged for use by other nodes in a networked environments. > > > Pag 3: > > Service description: Information about a networked service such as type of service, name of service, attributes of service, location of service, invocation of service. May be stored in a document or at a service repository > > > Confusion here (for me, it is not enough clear). I can't convince myself about what a "Service Repository" is: > > o) Service Repository: a peer containing related infos. > o) Service Repository: a boot strap server which allows to locate and exploit a p2p-based service. > o) A portion of the overlay. > o) A centralized component (see previous comment). > > But basically: "Is Service Repository, inside or outside the p2p- framework?" > Service repository is intended to cover architectures which store descriptions at a server (e.g., SLP, UDDI, LDAP) or proxy node. > > The expected volume of transactions expected in a global service discovery mechanism is in the range of DNS lookup volume. > > > How can justify such bound? "The expected volume of transactions expected in a global service discovery mechanism is in the range of DNS lookup volume." > I think it is an upper bound. It seems that service invocation frequency should be much higher than service discovery frequency. But service discovery < DNS lookups, in that hostname resolves due to say web browsing should occur at a higher frequency then service discovery requests. > > > Pag. 4 > > Use of multiple service description formats which might be tailored by application or level of semantic description > > > > I appreciate this point, really. > > > Access to services, service descriptions, and service advertisements dependent on authorization rights > > > > I can see HIP at the horizon... > > > The mechanism can be used in isolation by peers in PANs, ad hoc networks, or other limited networking environments > > > > Not clear what isolation is... > > That is, if say 5 peers are connected to each other but not to the Internet, they should still be able to do service discovery among each other. An example is if I have 5 devices in my PAN and I roaming disconnected from other networks. > > Pag. 5 > > > There are no new security considerations in this document. > > > I agree. In this incarnation the security considerations are not pertinent. > > _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 04:05:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1K6s-0003Xk-6R; Tue, 24 Jan 2006 04:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1K6p-0003X5-AR for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 04:05:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21259 for ; Tue, 24 Jan 2006 04:03:32 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1KGL-0000bD-D4 for p2prg@ietf.org; Tue, 24 Jan 2006 04:14:53 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0O94cB1011813; Tue, 24 Jan 2006 10:04:38 +0100 Received: from [138.96.250.105] (louis.inria.fr [138.96.250.105]) (authenticated bits=0) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0O91vZS010962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jan 2006 10:01:58 +0100 Message-ID: <43D5ED05.40300@sophia.inria.fr> Date: Tue, 24 Jan 2006 10:01:57 +0100 From: Arnaud Legout User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: buford@research.panasonic.com Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> In-Reply-To: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 24 Jan 2006 10:01:58 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id k0O94cB1011813 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: luca.caviglione@cnit.it, p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hello, buford@research.panasonic.com wrote: >> Further there are various peer-to-peer overlay networks and proposed d= esigns, both unstructured and structured by which large numbers of peers = share content and services. >> >> >> From a strict p2p point of view, there are also hybrid architectural f= lavors, such as BitTorrent. In hybrid frameworks, the centralized compone= nt plays a role (not being solely devoted to bootstrap). You know, people= out there have used client-server for decades, hence I would be a little= pragmatic. >> >> =20 > > > Yes agree. In fact the P2P overlay survey we posted had hybrid in the = taxonomy. > Good point. > > =20 The taxonomy based on structured, unstructured, and hybrid is focused on=20 the content localization of P2P. However, P2P is also about efficient content delivery. In particular, it is an error to classify BitTorrent as an hybrid=20 protocol. BitTorrent does not have any content localization feature. You find your content on a web site. BitTorrent can be possibly=20 classified, from a content localization point of view, as centralized. From my point of view, a better taxonomy for P2P is: *Content Localization -Structured -Unstructured -Centralized -Hybrid (?) *Content delivery -Parallel download -File splitting (swarming) -Piece selection -Peer selection This taxonomy must be refined, but at least, it takes into account both=20 content localization and content delivery. With this taxonomy, BitTorrent can now be correctly classified: Content Localization: centralized Content Delivery: Parallel download, File splitting, rarest first piece=20 selection, choke algorithm peer selection. Regards, Arnaud Legout. --=20 Arnaud Legout, Ph.D. INRIA Sophia Antipolis - Plan=E8te Phone : 00.33.4.92.38.78.15 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr FRANCE Web : http://www-sop.inria.fr/planete= /Arnaud.Legout/index.html _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 04:29:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1KUT-0001jU-Ch; Tue, 24 Jan 2006 04:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1KUQ-0001gc-20 for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 04:29:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22720 for ; Tue, 24 Jan 2006 04:27:54 -0500 (EST) Received: from brunello.labnet.cnit.it ([217.9.74.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Kdu-0001R1-J1 for p2prg@ietf.org; Tue, 24 Jan 2006 04:39:16 -0500 Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it (Postfix) with ESMTP id 923A54E850; Tue, 24 Jan 2006 10:28:54 +0100 (CET) Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02860-02-89; Tue, 24 Jan 2006 10:28:35 +0100 (CET) Received: from novello.labnet.cnit.it (ns.cnit.it [217.9.64.3]) by brunello.labnet.cnit.it (Postfix) with ESMTP id 4E1754E859; Tue, 24 Jan 2006 10:28:34 +0100 (CET) Received: from [130.251.11.101] (dhcp1.com.dist.unige.it [130.251.11.101]) by novello.labnet.cnit.it (Postfix) with ESMTP id 28F833C5E2; Tue, 24 Jan 2006 10:28:33 +0100 (CET) In-Reply-To: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09681C69-3F8F-4565-82AB-010CEBE0BAC8@cnit.it> Content-Transfer-Encoding: 7bit From: Luca Caviglione Subject: Re: [P2Prg] CORE subgroup problem statement Date: Tue, 24 Jan 2006 10:29:04 +0100 To: buford@research.panasonic.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Content-Transfer-Encoding: 7bit Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Dear John, than you for the good discussion. Some additional comments are below. Best Regards, Luca Il giorno 24/gen/06, alle ore 08:00, buford@research.panasonic.com ha scritto: >> >> >> I am not quite sure there are generality problems. At least, the >> concept of generality should be defined. What I think is valuable >> of p2p, is its ability of building overlays, and then allowing >> some kind of network independency (BTW, citing JXTA is something, >> that recalls this concept). Then, you should clarify what is >> generality for you and why you think p2p can change something. Is >> generality something related to "re-usability" or a more "smart" >> concept, such as the network independent deisgn? >> . > > > Yes, I agree that p2p overlay and index mechanisms are quite general. > But some p2p systems are application-specific (e.g., file sharing, > voip) > so not being general-purpose is meant from service-offering > standpoint. > So generality has to do, in my opinion, with supporting any type of > service. > Ok: supporting any type of service is a good concept. > >> >> >> Pag 2: >> >> The presented literature is quite comprehensive. However, I would >> consider as follows. >> >> >> Since we are talking about IETF, you can cite some good >> technologies, which are something related to service discovery. >> Mostly, they are suitable for local-small scale scenarios, but >> someone is thinking about enabling them for the global Internet. >> For instance: >> >> o) RFC 2782 "A DNS RR for specifying the location of services (DNS >> SRV)" http://www.ietf.org/rfc/rfc2782.txt >> >> o) The DNSService Discovery (http://www.dns-sd.org/). Besides, the >> DNS service discovery can be jointly used with the Multicast DNS >> (http://www.multicastdns.org/ and http://files.dns-sd.org/draft- >> cheshire-dnsext-nbp.txt). And of course, even if "human readable" >> and "rough", the DNS is related to "overlays". (http://files.dns- >> sd.org/ draft-cheshire-dnsext-dns-sd.txt) >> >> >> o) You can cite also Zeroconf (http://www.zeroconf.org/). >> >> o) And of course, one can exploit some mapping with underlying >> technologies, such as IPv6. >> > > > Yes, thanks for these suggestions. Definitely RFC2782 and > multicastdns and zeroconf. > However isn't IPv6 an enabling technology? > > Absolutely. I think IPv6 is a must for P2P. Anyway, let's see what happens about P2P and IPv6 :-) > > >> >> Typically large-scale unstructured peer-to-peer systems use >> limited scope flooding or random walk to reach other peers with >> requests... >> >> >> In hybrid systems, centralized component are used to locate peers >> and then directly route requests. >> >> For instance, in eMule (I am citing file-sharing since is quite >> popular), you can use 3 different architectural flavors: >> 1) use server to locate via e2DK >> 2) use Kad (XOR-based Chord DHT ring) >> 3) Exchange info via hording. >> >> >> Or in OpenNap >> 1)Use a OpenNap Server >> 2)Use a chained facility of OpenNap servers to route requests. >> >> However, the basic under such remarks is that "the more the >> unstructured p2p system is large, the worse the limited scope >> flooding performs". For this reason, supernodes, centralized >> components and so on have been introduced. >> >> Lastly, since it is a problem statement draft, I would mention >> that "limited scope flooding" does not allow to perform >> _exhaustive_ searches. Then we have to be honest: p2p is great for >> what you propose, but still need to be fixed. And in a problem >> statement draft, probably will be a nicer phrase. >> >> "Are you going to migrate DNS to an architecture that could be >> unable to resolve some URL, because peers responsible are too >> distant?" >> > > > Good points, this can be cited, do you suggest citations for eMule > and OpenNap > technical details? > Also, we kept the overlay discussion short in the problem statement > since > we have proposed in the charter to prepare a separate survey document. > So some of this discussion might go there. > > Regarding the chance of not finding something that is stored > somewhere in the overlay, > yes it doesn't seem like a desirable scenario. > > What would be nice from a research standpoint is to have a > probabilistic formula > as a function of size, architecture, churn, average node lifetime, > replication rate, > and index pollution, etc. of finding an item stored in the overlay. > Personally, I think you can avoid citing eMule and OpenNap. I mean, it is not mandatory, but many guys use them and they are well-known. You can just introduce that some p2p systems have problem in searches (and of course expanding this in the survey as you suggested). Besides, I think that the probabilistic formula is the right and better answer for convincing/describing p2p - search characteristics. Let me know if you need help in the survey... > >> >> Search: a discovery mechanism in which content or resources stored >> in a peer-to-peer network can be searched using various methods >> including text search, keyword search, content-based retrieval or >> meta-data search >> >> >> >> Are they stored in the p2p network? Or are they stored in peers? >> >> >> My 2 cents: >> >> -)how the overlay is "built" states intrinsically _how to >> retrieve_ (e.g., A DNS based Overlay roughly corresponds to text >> search). >> >> >> -)peers belonging to a given overlay _store_ the content or >> resources. >> >> >> (??? I am not fond of CDN, but CDN-literature should be inspiring) >> > > > Why is the distinction between storage in the peer vs p2p network > important? > Consider a system like OpenDHT where some node which is not part of > the > p2p system can insert and lookup into a p2p index formed by another > set of > nodes. from the client node standpoint, the p2p index could just > as well > be a single server, and the storage is somewhere in the collection > of nodes, > hence "p2p network". Also there is the case of replicated entries, > and > cases where we might split up an object into parts before indexing > each part. > Good point. I agree. > > >> >> Service: a computational function packaged for use by other nodes >> in a networked environment . >> >> >> It sounds like "RPCs" or "Stored Procedure" stuff. It is quite >> clear the idea, but for my personal style I would avoid >> "computational"... "a portion of peer resource" is more general >> (maybe when you'll define your architectures, you'll have storage- >> peers, computing- peers... hence, it is more general). >> > > > How about: > Service: an interface to a resource packaged for use by other nodes > in a networked environments. > Perfect, I like it very much. > >> >> >> Pag 3: >> >> Service description: Information about a networked service such as >> type of service, name of service, attributes of service, location >> of service, invocation of service. May be stored in a document or >> at a service repository >> >> >> Confusion here (for me, it is not enough clear). I can't convince >> myself about what a "Service Repository" is: >> >> o) Service Repository: a peer containing related infos. >> o) Service Repository: a boot strap server which allows to locate >> and exploit a p2p-based service. >> o) A portion of the overlay. >> o) A centralized component (see previous comment). >> >> But basically: "Is Service Repository, inside or outside the p2p- >> framework?" >> > > > Service repository is intended to cover architectures which store > descriptions at a server > (e.g., SLP, UDDI, LDAP) or proxy node. > Clear, now. > >> >> The expected volume of transactions expected in a global service >> discovery mechanism is in the range of DNS lookup volume. >> >> >> How can justify such bound? "The expected volume of transactions >> expected in a global service discovery mechanism is in the range >> of DNS lookup volume." >> > > > > I think it is an upper bound. It seems that service invocation > frequency should be much > higher than service discovery frequency. But service discovery < > DNS lookups, in that > hostname resolves due to say web browsing should occur at a higher > frequency then > service discovery requests. > > > > That is, if say 5 peers are connected to each other but not to the > Internet, they > should still be able to do service discovery among each other. > An example is if I have 5 devices in my PAN and I roaming > disconnected from > other networks. > > Good points. _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 04:55:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1KtG-0000Oz-S7; Tue, 24 Jan 2006 04:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1KtF-0000Oo-7W for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 04:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24331 for ; Tue, 24 Jan 2006 04:53:35 -0500 (EST) Received: from brunello.labnet.cnit.it ([217.9.74.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1L2l-0002Ig-Oo for p2prg@ietf.org; Tue, 24 Jan 2006 05:04:56 -0500 Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it (Postfix) with ESMTP id 422194E849; Tue, 24 Jan 2006 10:54:54 +0100 (CET) Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05516-01-5; Tue, 24 Jan 2006 10:54:32 +0100 (CET) Received: from novello.labnet.cnit.it (ns.cnit.it [217.9.64.3]) by brunello.labnet.cnit.it (Postfix) with ESMTP id C760E4E5D3; Tue, 24 Jan 2006 10:54:32 +0100 (CET) Received: from [130.251.11.101] (dhcp1.com.dist.unige.it [130.251.11.101]) by novello.labnet.cnit.it (Postfix) with ESMTP id 2EE1C3C5E2; Tue, 24 Jan 2006 10:54:31 +0100 (CET) In-Reply-To: <43D5ED05.40300@sophia.inria.fr> References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> Content-Transfer-Encoding: quoted-printable From: Luca Caviglione Subject: Re: [P2Prg] CORE subgroup problem statement Date: Tue, 24 Jan 2006 10:55:17 +0100 To: Arnaud Legout X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hi Arnaud, some comments in-line. Best Regards, Luca Il giorno 24/gen/06, alle ore 10:01, Arnaud Legout ha scritto: > The taxonomy based on structured, unstructured, and hybrid is =20 > focused on the content localization of P2P. > However, P2P is also about efficient content delivery. Yes, of course. > In particular, it is an error to classify BitTorrent as an hybrid =20 > protocol. BitTorrent does not have any content localization feature. > You find your content on a web site. BitTorrent can be possibly =20 > classified, from a content localization point of view, > as centralized. I would not start a flame about "terminology" :-). However, hybrid =20 protocol is something I don't like in this context. In fact, I used =20 "architectural", rather than protocol. So, I think there are not =20 errors in defying BitTorrent as an hybrid architecture. Actually, =20 there are two architectural flavors overlapped: centralized, from "a =20 content localization point of view" and p2p for the swarm. Hybrid Protocol suggests functionalities and does not lead to a =20 better understanding of "how the architecture is arranged". > > =46rom my point of view, a better taxonomy for P2P is: > *Content Localization > -Structured > -Unstructured > -Centralized > -Hybrid (?) > *Content delivery > -Parallel download > -File splitting (swarming) > -Piece selection > -Peer selection In my opinion, what you suggest is somewhat misleading. I mean, =20 parallel download, file-splitting, piece selection... are techniques =20 for delivering a file over a network and are not strictly related =20 with p2p. The only requirement is that content is replicated among =20 several entities. Then with your taxonomy, I can describe as p2p "GetRight", the FTP =20 client for Windows. With GetRight you can set mirrors and =20 concurrently download from different FTP servers. Ok, this is an =20 exasperation of the concept, but I think that architectures must be =20 separated from peculiar tricks. > > This taxonomy must be refined, but at least, it takes into account =20 > both content localization and content delivery. > With this taxonomy, BitTorrent can now be correctly classified: > Content Localization: centralized > Content Delivery: Parallel download, File splitting, rarest first =20 > piece selection, choke algorithm peer selection. I think you did not classified BitTorrent. You are only listing some =20 techniques used for achieving a better efficiency on the networked =20 environment. > > Regards, > Arnaud Legout. Regards, Luca > --=20 > Arnaud Legout, Ph.D. > > INRIA Sophia Antipolis - Plan=E8te Phone : 00.33.4.92.38.78.15 > 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 > 06902 Sophia Antipolis CEDEX E-mail: =20 > arnaud.legout@sophia.inria.fr > FRANCE Web : http://www-sop.inria.fr/=20 > planete/Arnaud.Legout/index.html > > > > _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 12:35:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S4b-0005nq-Nd; Tue, 24 Jan 2006 12:35:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S4a-0005nl-HA for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 12:35:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03092 for ; Tue, 24 Jan 2006 12:33:46 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1SEA-0003sA-0x for p2prg@ietf.org; Tue, 24 Jan 2006 12:45:11 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OHZ06J028935; Tue, 24 Jan 2006 18:35:00 +0100 Received: from [138.96.250.105] (louis.inria.fr [138.96.250.105]) (authenticated bits=0) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OHWMLU028242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jan 2006 18:32:23 +0100 Message-ID: <43D664A5.70205@sophia.inria.fr> Date: Tue, 24 Jan 2006 18:32:21 +0100 From: Arnaud Legout User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Luca Caviglione Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> In-Reply-To: <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 24 Jan 2006 18:32:23 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hi Luca, Luca Caviglione wrote: >> You find your content on a web site. BitTorrent can be possibly >> classified, from a content localization point of view, >> as centralized. > In particular, it is an error to classify BitTorrent as an hybrid > protocol. BitTorrent does not have any content localization feature. > > > I would not start a flame about "terminology" :-). However, hybrid > protocol is something I don't like in this context. In fact, I used > "architectural", rather than protocol. So, I think there are not > errors in defying BitTorrent as an hybrid architecture. Actually, > there are two architectural flavors overlapped: centralized, from "a > content localization point of view" and p2p for the swarm. > Hybrid Protocol suggests functionalities and does not lead to a better > understanding of "how the architecture is arranged". > I don't agree. When you classify architectures as structured and unstructured, hybrid should mean that you have a combination of structured and unstructured. Otherwise, hybrid is for everything you don't know how to classify. "Other" would have been a better name, but still a weak classification. It is not correct to classify some protocol based on their localization architecture and some other protocols based on their content replication architecture, without making a clear distinction in the taxonomy. If you consider BitTorrent to be an hybrid architecture because there is a central content localization and p2p file replication, then any other P2P protocol should be hybrid. Instead, using your taxonomy BT should be considered as centralized. I do not believe I am raising a flame about terminology. I simply want to point out that the way P2P is considered for now is content localization oriented. This is only one side of P2P, and content localization and content replication should be uncorrelated. BitTorrent, which is undoubtedly the most efficient general purpose P2P protocol, cannot be classified using the current taxonomy. Thus, this taxonomy do not cover all the P2P architectures. > >> >> From my point of view, a better taxonomy for P2P is: >> *Content Localization >> -Structured >> -Unstructured >> -Centralized >> -Hybrid (?) >> *Content delivery >> -Parallel download >> -File splitting (swarming) >> -Piece selection >> -Peer selection > > In my opinion, what you suggest is somewhat misleading. I mean, > parallel download, file-splitting, piece selection... are techniques > for delivering a file over a network and are not strictly related with > p2p. The only requirement is that content is replicated among several > entities. > Then with your taxonomy, I can describe as p2p "GetRight", the FTP > client for Windows. With GetRight you can set mirrors and concurrently > download from different FTP servers. Ok, this is an exasperation of > the concept, but I think that architectures must be separated from > peculiar tricks. > I am not sure it is possible to abstract the architecture from the technique..Unstructured is not specific to P2P as well. Multicast has been using this kind of architectures and techniques (flooding, expanding ring search, etc.) for a long time. Structured is not specific to P2P as well, unless you mean Structured=DHT, but in this case you are no more making a distinction between architecture and technique. Using the current taxonomy you can already classify protocols that are not P2P. You are right that my taxonomy is technique oriented rather architecture oriented. For all the P2P protocols I know, structured means DHT, and unstructured means flooding, expanding ring search, random walk, etc. I would really prefer a taxonomy using DHT, flooding, expanding ring search, etc. than structured and unstructured. >> This taxonomy must be refined, but at least, it takes into account >> both content localization and content delivery. >> With this taxonomy, BitTorrent can now be correctly classified: >> Content Localization: centralized >> Content Delivery: Parallel download, File splitting, rarest first >> piece selection, choke algorithm peer selection. > > > I think you did not classified BitTorrent. You are only listing some > techniques used for achieving a better efficiency on the networked > environment. > When you classify Chord as structured, don't you mean it is a DHT? Do you have an example of structured P2P architecture that is not a DHT? From my point of view, DHT is at the same semantic level than piece selection, and Chord is at the same semantic level than rarest first. I don't know which definition of structured and unstructured architecture you consider, but the one presented in [1] is technique dependent and vague. Structured is for DHT, unstructured is for other localization techniques. Regards, Arnaud. [1] Lua et al. "A Survey and Comparison of Peer-to-Peer Overlay Network Schemes" IEEE Communication s survey and tutorial, March 2004 _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 13:01:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1STl-0004tN-S4; Tue, 24 Jan 2006 13:01:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1STk-0004tI-4t for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 13:01:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04882 for ; Tue, 24 Jan 2006 12:59:45 -0500 (EST) Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1SdK-0004m0-5Y for p2prg@ietf.org; Tue, 24 Jan 2006 13:11:11 -0500 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id C0E44D2F8B4; Tue, 24 Jan 2006 13:01:04 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 24 Jan 2006 13:01:04 -0500 X-Sasl-enc: 9JL/1OVPbmgR3WUQf0yERazp/MTUwNq57DQ7fDsVXcs9 1138125663 Received: from [192.168.0.3] (adsl-70-231-230-125.dsl.snfc21.sbcglobal.net [70.231.230.125]) by frontend2.messagingengine.com (Postfix) with ESMTP id AB7E257146C; Tue, 24 Jan 2006 13:00:59 -0500 (EST) In-Reply-To: <43D5ED05.40300@sophia.inria.fr> References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Bill Yeager Subject: Re: [P2Prg] CORE subgroup problem statement Date: Tue, 24 Jan 2006 10:00:34 -0800 To: Arnaud Legout X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: luca.caviglione@cnit.it, p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039448679==" Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org --===============0039448679== Content-Type: multipart/alternative; boundary=Apple-Mail-2-904644290 --Apple-Mail-2-904644290 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Bonjour Arnold, Your taxonomy seems to be restricted to file sharing or at least the delivery of content. While the latter is general I think you mean reasonably sized files. What about communities, and messaging in general? One can easily do text messaging (SMS or MMS like), play games, and email within a P2P taxonomy for example. In particular with a community structure imposed for communication, ie, all communication is intra-community, the yield is a virtual private network if one adds TLS, and public key authentication as a participation in a community requirement. This quickly gets us to SPAM less communication, etc. P2P is quite rich and the application/services one can map onto the right system diverse. Just a thought, Bill On Jan 24, 2006, at 1:01 AM, Arnaud Legout wrote: > From my point of view, a better taxonomy for P2P is: > *Content Localization > -Structured > -Unstructured > -Centralized > -Hybrid (?) > *Content delivery > -Parallel download > -File splitting (swarming) > -Piece selection > -Peer selection --Apple-Mail-2-904644290 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bonjour Arnold,

Your taxonomy seems to be = restricted to file sharing or at least the delivery of content. While = the latter is general I think you mean reasonably sized files. What = about communities, and messaging in general? One can easily do text = messaging (SMS or MMS like), play games, and email within a P2P taxonomy = for example.=A0

In particular with a = community structure imposed for communication, ie, all communication is = intra-community, the yield is a virtual private network if one adds TLS, = and public key authentication as a participation in a community = requirement. This quickly gets us to SPAM less communication, = etc.

P2P is = quite rich and the application/services one can map onto the right = system diverse.

Just a = thought,

Bill

On = Jan 24, 2006, at 1:01 AM, Arnaud Legout wrote:

=46rom my point of view, a = better taxonomy for P2P is:

*Content Localization

=A0-Structured

=A0-Unstructured

=A0-Centralized

=A0-Hybrid (?)

*Content delivery

=

=A0-Parallel download

=

=A0-File splitting=A0 (swarming)

=A0-Piece selection

=A0-Peer selection

=

= --Apple-Mail-2-904644290-- --===============0039448679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg --===============0039448679==-- From p2prg-bounces@ietf.org Tue Jan 24 14:20:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1TiD-0001Xg-Fl; Tue, 24 Jan 2006 14:20:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1TiB-0001XZ-6I for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 14:20:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11013 for ; Tue, 24 Jan 2006 14:18:44 -0500 (EST) Received: from brunello.labnet.cnit.it ([217.9.74.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Trm-0007nj-9L for p2prg@ietf.org; Tue, 24 Jan 2006 14:30:10 -0500 Received: from localhost (localhost [127.0.0.1]) by brunello.labnet.cnit.it (Postfix) with ESMTP id 70DF34E5D3; Tue, 24 Jan 2006 20:20:02 +0100 (CET) Received: from brunello.labnet.cnit.it ([127.0.0.1]) by localhost (brunello [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31389-04-2; Tue, 24 Jan 2006 20:19:44 +0100 (CET) Received: by brunello.labnet.cnit.it (Postfix, from userid 33) id 5A1264E639; Tue, 24 Jan 2006 20:19:44 +0100 (CET) Received: from host208-59.pool8260.interbusiness.it (host208-59.pool8260.interbusiness.it [82.60.59.208]) by webmail.cnit.it (IMP) with HTTP for ; Tue, 24 Jan 2006 20:19:44 +0100 Message-ID: <1138130384.43d67dd03247c@webmail.cnit.it> Date: Tue, 24 Jan 2006 20:19:44 +0100 From: Luca Caviglione To: Arnaud Legout Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> <43D664A5.70205@sophia.inria.fr> In-Reply-To: <43D664A5.70205@sophia.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 82.60.59.208 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cnit.it Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hi Arnaud ... Quoting Arnaud Legout : > Hi Luca, > > > > I would not start a flame about "terminology" :-). However, hybrid > > protocol is something I don't like in this context. In fact, I used > > "architectural", rather than protocol. So, I think there are not > > errors in defying BitTorrent as an hybrid architecture. Actually, > > there are two architectural flavors overlapped: centralized, from "a > > content localization point of view" and p2p for the swarm. > > Hybrid Protocol suggests functionalities and does not lead to a bette= r > > understanding of "how the architecture is arranged". > > > > I don't agree. When you classify architectures as structured and > unstructured, hybrid should mean that you have a combination of > structured and unstructured. > Otherwise, hybrid is for everything you don't know how to classify. > "Other" would have been a better name, but still a weak classification. I do agree here. Other is a better name and also a weak classification. H= owever, I think that correct classification (better, the one I would prefer) must= rely on architectures, rather than functionalities. > It is not correct to classify some protocol based on their localization > architecture and some other protocols based on their content replicatio= n > architecture, > without making a clear distinction in the taxonomy. > If you consider BitTorrent to be an hybrid architecture because there i= s > a central content localization and p2p file replication, then > any other P2P protocol should be hybrid. Instead, using your taxonomy B= T > should be considered as centralized. Actually, BitTorrent is a superposition of two protocols. The BT-Tracker protocol and the BT protocol for the swarm. Then, the protocols reflect t= he architecture where they act. However, this is my perspective and it doesn= 't mean it is the best one or better than others. > > I do not believe I am raising a flame about terminology. Yes, sorry. I was suggesting (for my answer) that it is not solely a deba= te for "terms". > I simply want to point out that the way P2P is considered for now is > content localization oriented. > This is only one side of P2P, and content localization and content > replication should be uncorrelated. > BitTorrent, which is undoubtedly the most efficient general purpose P2P > protocol, cannot be classified > using the current taxonomy. > Thus, this taxonomy do not cover all the P2P architectures. > > > > >> > >> From my point of view, a better taxonomy for P2P is: > >> *Content Localization > >> -Structured > >> -Unstructured > >> -Centralized > >> -Hybrid (?) > >> *Content delivery > >> -Parallel download > >> -File splitting (swarming) > >> -Piece selection > >> -Peer selection > > > > In my opinion, what you suggest is somewhat misleading. I mean, > > parallel download, file-splitting, piece selection... are techniques > > for delivering a file over a network and are not strictly related wit= h > > p2p. The only requirement is that content is replicated among several > > entities. > > Then with your taxonomy, I can describe as p2p "GetRight", the FTP > > client for Windows. With GetRight you can set mirrors and concurrentl= y > > download from different FTP servers. Ok, this is an exasperation of > > the concept, but I think that architectures must be separated from > > peculiar tricks. > > > > I am not sure it is possible to abstract the architecture from the > technique..Unstructured is not specific to P2P as well. Multicast has > been using this kind of architectures and techniques (flooding, > expanding ring search, etc.) for a long time. I partially agree. However, I think that the first step, in order to prod= uce a taxonomy, is to separate causes with effects. You can use swarming, hordi= ng (or flooding and expanding ring) since the architectural blueprints allow suc= h techniques. > Structured is not specific to P2P as well, unless you mean > Structured=3DDHT, but in this case you are no more making a distinction > between architecture > and technique. > Using the current taxonomy you can already classify protocols that are > not P2P. > > You are right that my taxonomy is technique oriented rather architectur= e > oriented. > For all the P2P protocols I know, structured means DHT, and unstructure= d > means flooding, expanding ring search, random walk, etc. > I would really prefer a taxonomy using DHT, flooding, expanding ring > search, etc. than structured and unstructured. For me, structured means that there is an enforcement in the organization= of peers. Having the peers forced to arrange in a ring (as an example) allow= s to exploit some search strategies. On the contrary, having peers connected randomly, brings you in the case where you don't know where the content i= s. So you must flood or something else. > > >> This taxonomy must be refined, but at least, it takes into account > >> both content localization and content delivery. > >> With this taxonomy, BitTorrent can now be correctly classified: > >> Content Localization: centralized > >> Content Delivery: Parallel download, File splitting, rarest first > >> piece selection, choke algorithm peer selection. > > > > > > I think you did not classified BitTorrent. You are only listing some > > techniques used for achieving a better efficiency on the networked > > environment. > > > When you classify Chord as structured, don't you mean it is a DHT? Do > you have an example of structured P2P architecture that is not a DHT? > > From my point of view, DHT is at the same semantic level than piece > selection, and Chord is at the same semantic level than rarest first. This is an interesting point. > I don't know which definition of structured and unstructured > architecture you consider, but the one presented in [1] is technique > dependent and vague. > Structured is for DHT, unstructured is for other localization technique= s. > ...and probably is there the main knot. For me, unstructured and structur= ed is how "the peers are organized" and not related to localization techniques.= I mean, if I am going crazy, I can use a flood based technique selecting ra= ndomly peers in Chord's finger tables (and probably I can patent this as the use= less search system ever). > Regards, > Arnaud. Regards, Luca > > > [1] Lua et al. "A Survey and Comparison of Peer-to-Peer Overlay Network > Schemes" IEEE Communication s survey and tutorial, March 2004 > > > _______________________________________________ > P2prg mailing list > P2prg@irtf.org > https://www1.ietf.org/mailman/listinfo/p2prg > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 16:32:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VmX-0000Jy-Eh; Tue, 24 Jan 2006 16:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VmV-0000G1-O4 for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 16:32:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02007 for ; Tue, 24 Jan 2006 16:31:19 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Vw4-0008L1-UZ for p2prg@ietf.org; Tue, 24 Jan 2006 16:42:48 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OLWVAW022877; Tue, 24 Jan 2006 22:32:31 +0100 Received: from [192.168.0.10] (vau06-1-82-228-252-129.fbx.proxad.net [82.228.252.129]) (authenticated bits=0) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OLWUKj022863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jan 2006 22:32:31 +0100 Message-ID: <43D69CED.7060702@sophia.inria.fr> Date: Tue, 24 Jan 2006 22:32:29 +0100 From: Arnaud Legout User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Luca Caviglione Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> <43D664A5.70205@sophia.inria.fr> <1138130384.43d67dd03247c@webmail.cnit.it> In-Reply-To: <1138130384.43d67dd03247c@webmail.cnit.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 24 Jan 2006 22:32:31 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: p2prg@ietf.org X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hi Luca, Luca Caviglione wrote: > I do agree here. Other is a better name and also a weak classification. However, > I think that correct classification (better, the one I would prefer) must rely > on architectures, rather than functionalities. > I am not sure I understand why you want to focus on architecture. As you said below, that only gives you information on how peers are organized. They what can you do with that? A taxonomy should have an intent, when it is based on functionality it offers a classification of building blocks that can be used to design new protocols. At least, I would have understood a refined taxonomy based on architecture. But the taxonomy structured/unstructured is too coarse to be useful. > > Actually, BitTorrent is a superposition of two protocols. The BT-Tracker > protocol and the BT protocol for the swarm. Then, the protocols reflect the > architecture where they act. However, this is my perspective and it doesn't > mean it is the best one or better than others. > Now, I see why you classify it as hybrid, but here again I do not see how this classification is useful. I expect from a taxonomy to be able to compare protocols within the same classification. But, protocols classified as structured, unstructured and hybrid are so different, that I cannot really compare them. >> >> I am not sure it is possible to abstract the architecture from the >> technique..Unstructured is not specific to P2P as well. Multicast has >> been using this kind of architectures and techniques (flooding, >> expanding ring search, etc.) for a long time. >> > > I partially agree. However, I think that the first step, in order to produce a > taxonomy, is to separate causes with effects. You can use swarming, hording (or > flooding and expanding ring) since the architectural blueprints allow such > techniques. > I am not sure what you mean by cause and effect. If you mean architecture and functionality, I am not sure that starting with architecture is the right first step. My argument is that in the context of P2P the architecture, i.e., how peers are arranged, does not give you much information. I agree it is better than nothing, but a taxonomy based on functionality would be more useful. > For me, structured means that there is an enforcement in the organization of > peers. Having the peers forced to arrange in a ring (as an example) allows to > exploit some search strategies. On the contrary, having peers connected > randomly, brings you in the case where you don't know where the content is. So > you must flood or something else. > I see, but you can have peer structured in a ring for content localization or for file replication (I agree this is not the best architecture for file replication, this is just for the example). The case of unstructured is more realistic. You can have a random graph connectivity for content localization or for content replication. Thus, knowing that your protocol is classified as structured or unstructured is not of much help. > ...and probably is there the main knot. For me, unstructured and structured is > how "the peers are organized" and not related to localization techniques. I > mean, if I am going crazy, I can use a flood based technique selecting randomly > peers in Chord's finger tables (and probably I can patent this as the useless > search system ever). > and that is my point (I am starting to be very redundant), the taxonomy based on structured and unstructured does not give you a very useful information. Regards, Arnaud. _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 24 16:36:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Vpz-0001nA-9L; Tue, 24 Jan 2006 16:36:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Vpx-0001m5-Ac for p2prg@megatron.ietf.org; Tue, 24 Jan 2006 16:36:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02801 for ; Tue, 24 Jan 2006 16:34:53 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VzX-0000EH-3R for p2prg@ietf.org; Tue, 24 Jan 2006 16:46:22 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OLaCov023702; Tue, 24 Jan 2006 22:36:12 +0100 Received: from [192.168.0.10] (vau06-1-82-228-252-129.fbx.proxad.net [82.228.252.129]) (authenticated bits=0) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OLa6Gk023677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jan 2006 22:36:07 +0100 Message-ID: <43D69DC6.7010403@sophia.inria.fr> Date: Tue, 24 Jan 2006 22:36:06 +0100 From: Arnaud Legout User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: p2prg@ietf.org Subject: [Fwd: Re: [P2Prg] CORE subgroup problem statement] Content-Type: multipart/mixed; boundary="------------010605010409050802060104" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 24 Jan 2006 22:36:07 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org This is a multi-part message in MIME format. --------------010605010409050802060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I forgot to cc the mailing list. Arnaud. --------------010605010409050802060104 Content-Type: message/rfc822; name="Re: [P2Prg] CORE subgroup problem statement" Content-Disposition: inline; filename="Re: [P2Prg] CORE subgroup problem statement" Return-Path: Received: from eurus1.inria.fr ([unix socket]) by imap-sop.inria.fr (Cyrus v2.2.12) with LMTPA; Tue, 24 Jan 2006 21:48:23 +0100 X-Sieve: CMU Sieve 2.2 Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by eurus1.inria.fr (8.12.11/8.12.5) with ESMTP id k0OKmLuV016316 for ; Tue, 24 Jan 2006 21:48:21 +0100 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OKmJg9013841; Tue, 24 Jan 2006 21:48:19 +0100 Received: from [192.168.0.10] (vau06-1-82-228-252-129.fbx.proxad.net [82.228.252.129]) (authenticated bits=0) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id k0OKmBxE013823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jan 2006 21:48:14 +0100 Message-ID: <43D6928A.6040008@sophia.inria.fr> Date: Tue, 24 Jan 2006 21:48:10 +0100 From: Arnaud Legout User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bill Yeager Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 24 Jan 2006 21:48:14 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Flag: NO X-Scanned-By: milter-spamc/0.25.321 (imap-sop.inria.fr [138.96.64.23]); Tue, 24 Jan 2006 21:48:23 +0100 X-Spam-Status: NO, hits=-2.60 required=5.00 X-Spam-Level: X-Spam-Report: Spam detection software, running on the system "eurus1.inria.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster@sophia.inria.fr for details. ____ Content preview: Hello Bill, Bill Yeager wrote > Your taxonomy seems to be restricted to file sharing or at least the > delivery of content. While the latter is general I think you mean > reasonably sized files. What about communities, and messaging in > general? One can easily do text messaging (SMS or MMS like), play > games, and email within a P2P taxonomy for example. right. my taxonomy is by no way exhaustive. It is simply what I believe to be an enhancement compared to the classical structured/unstructured one. This new taxonomy takes into account in addition to the old one file delivery. It takes also into account small file delivery (MMS, etc.) as even in this case you have to perform peer selection, and perhaps piece selection if it makes sense to split the content (perhaps slow terminals with heterogeneous capacities) There are probably fundamental characteristics I do not take into account in the case of small file download, but it is a starting point. > > In particular with a community structure imposed for communication, > ie, all communication is intra-community, the yield is a virtual > private network if one adds TLS, and public key authentication as a > participation in a community requirement. This quickly gets us to SPAM > less communication, etc. > > P2P is quite rich and the application/services one can map onto the > right system diverse. I agree, but as you said P2P is quite rich and it was not my intent to give a taxonomy that fit all cases. I restrict myself to the case of P2P file transfer/localization. Then it is possible to add new branches to this taxonomy. Given the complexity of P2P, it would not be reasonable to start with a general purpose taxonomy. [...] ____ Content analysis details: (-2.6 points, 5.0 required) ____ pts rule name description ---- ---------------------- -------------------------------------------------- -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] ____ Content-Transfer-Encoding: 7bit Hello Bill, Bill Yeager wrote > Your taxonomy seems to be restricted to file sharing or at least the > delivery of content. While the latter is general I think you mean > reasonably sized files. What about communities, and messaging in > general? One can easily do text messaging (SMS or MMS like), play > games, and email within a P2P taxonomy for example. right. my taxonomy is by no way exhaustive. It is simply what I believe to be an enhancement compared to the classical structured/unstructured one. This new taxonomy takes into account in addition to the old one file delivery. It takes also into account small file delivery (MMS, etc.) as even in this case you have to perform peer selection, and perhaps piece selection if it makes sense to split the content (perhaps slow terminals with heterogeneous capacities) There are probably fundamental characteristics I do not take into account in the case of small file download, but it is a starting point. > > In particular with a community structure imposed for communication, > ie, all communication is intra-community, the yield is a virtual > private network if one adds TLS, and public key authentication as a > participation in a community requirement. This quickly gets us to SPAM > less communication, etc. > > P2P is quite rich and the application/services one can map onto the > right system diverse. I agree, but as you said P2P is quite rich and it was not my intent to give a taxonomy that fit all cases. I restrict myself to the case of P2P file transfer/localization. Then it is possible to add new branches to this taxonomy. Given the complexity of P2P, it would not be reasonable to start with a general purpose taxonomy. Regards, Arnaud --------------010605010409050802060104 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg --------------010605010409050802060104-- From p2prg-bounces@ietf.org Wed Jan 25 05:03:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1hUk-0001Pn-N1; Wed, 25 Jan 2006 05:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1hUj-0001Pe-9M for p2prg@megatron.ietf.org; Wed, 25 Jan 2006 05:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27278 for ; Wed, 25 Jan 2006 05:01:45 -0500 (EST) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1heR-0001zy-P8 for p2prg@ietf.org; Wed, 25 Jan 2006 05:13:21 -0500 Received: from eapoffice3.langcen.ucl.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Wed, 25 Jan 2006 10:02:52 +0000 Message-ID: <43D74D5B.9030803@cs.ucl.ac.uk> Date: Wed, 25 Jan 2006 10:05:15 +0000 From: Michael Rogers User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: p2prg@ietf.org Subject: Re: [P2Prg] CORE subgroup problem statement References: <158db13194.13194158db@pintlmail.MITL.Research.Panasonic.COM> <43D5ED05.40300@sophia.inria.fr> <4AF951D0-A059-476F-B511-E73B04794B90@cnit.it> <43D664A5.70205@sophia.inria.fr> <1138130384.43d67dd03247c@webmail.cnit.it> <43D69CED.7060702@sophia.inria.fr> In-Reply-To: <43D69CED.7060702@sophia.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Hi Arnaud, Arnaud Legout wrote: > My argument is that in the context of P2P the architecture, i.e., how > peers are arranged, does not give you much information. On the other hand there are some situations (P2P over wireless, NATs and firewalls, F2F) where you have to work with the topology you're given, and it's useful to know which protocols are suitable for those (maybe not "unstructured" but "unstructurable") networks. > I agree it is better than nothing, but a taxonomy based on functionality > would be more useful. Perhaps the two are orthogonal - if not, it might be enlightening to find out why not. Cheers, Michael _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Fri Jan 27 13:06:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Xzr-0001aL-JA; Fri, 27 Jan 2006 13:06:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Xzp-0001a5-WD for p2prg@megatron.ietf.org; Fri, 27 Jan 2006 13:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01063 for ; Fri, 27 Jan 2006 13:05:20 -0500 (EST) Received: from mailscanner1.stir.ac.uk ([139.153.12.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2YA1-0008L5-Hp for p2prg@ietf.org; Fri, 27 Jan 2006 13:17:26 -0500 Received: from [139.153.254.70] (helo=yen.cs.stir.ac.uk) by mailscanner1.stir.ac.uk with esmtp (Exim 4.50) id 1F2XxG-0001IJ-Cc for p2prg@ietf.org; Fri, 27 Jan 2006 18:04:14 +0000 Received: by yen.cs.stir.ac.uk (8.9.3) id SAA09596; Fri, 27 Jan 2006 18:06:28 GMT From: "Alan Brown" Received: from user-2158.lns4-c8.dsl.pol.co.uk ([84.67.136.110]) (SquirrelMail authenticated user abr) by www.cs.stir.ac.uk with HTTP; Fri, 27 Jan 2006 18:06:28 -0000 (GMT) Message-ID: <1457.84.67.136.110.1138385188.squirrel@www.cs.stir.ac.uk> Date: Fri, 27 Jan 2006 18:06:28 -0000 (GMT) To: p2prg@ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20060127180628_24746" X-stir.ac.uk-MailScanner: Found to be clean X-stir.ac.uk-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.82, required 5, ALL_TRUSTED -2.82) X-stir.ac.uk-MailScanner-From: abr@cs.stir.ac.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Subject: [P2Prg] Simulation tools for p2prg core subgroup X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org ------=_20060127180628_24746 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, For the core subgroup experimental work item, we have prepared the attached draft summarizing existing free network simulation tools. If anyone has any comments or contributions they would like to make, they are most welcome. Thanks. -- Alan Brown PhD Research Student Department of Computing Science and Mathematics University of Stirling, FK9 4LA Office: 4B49 Tel: +441786 467449, Web: http://www.cs.stir.ac.uk/~abr -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. ------=_20060127180628_24746 Content-Type: text/plain; name="draft-irtf-p2prg-core-simulators-00.txt" Content-Disposition: attachment; filename="draft-irtf-p2prg-core-simulators-00.txt" Content-Transfer-Encoding: 8bit IRTF P2PRG A. Brown Internet Draft Stirling Expires: July 26, 2006 M. Kolberg Stirling January 27, 2006 Tools for Peer-to-Peer Network Simulation draft-irtf-p2prg-core-simulators-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 30,2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract Due to the extremely large scale of P2P overlay networks, complexity has become a major issue. With the number of connected nodes reaching into the millions, a platform which can accurately simulate an overlay network is important. Many freely available network Brown Expires July 26, 2006 [Page 1] Internet-Draft Tools for P2P Network Simulation January 2006 simulators exist, ranging from modelling networks at the packet level to concentrating purely on the overlay network. The following document provides an overview of these simulators, documenting the maximum number of simulated nodes achieved in experiments, the P2P overlay architectures modelled and the chosen implementation language. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Overlay Network Simulators.....................................3 2.1. Narses....................................................3 2.2. 3LS.......................................................4 2.3. NeuroGrid.................................................4 2.4. PeerSim...................................................5 2.5. P2PSim....................................................5 3. Packet level Network Simulators................................6 3.1. Omnet++...................................................6 3.2. NS2.......................................................6 3.3. SSFNet....................................................7 4. Summary........................................................8 5. Security Considerations........................................9 6. References....................................................10 6.1. Normative References.....................................10 6.2. Informative References...................................10 Author's Addresses...............................................11 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgment...................................................12 1. Introduction To support the performance work of service overlays to be undertaken by the P2PRG CORE subgroup, we are examining existing simulation tools for suitability. This document summarizes information we have collected to date, covering only freely available simulation tools. Simulating Peer-to-Peer (P2P) overlay networks is a common problem for researchers/developers. Firstly, P2P overlay networks need to be scalable (Kazaa has more than 4 million simultaneous users) and Brown Expires July 26, 2006 [Page 2] Internet-Draft Tools for P2P Network Simulation January 2006 creating a simulation for such a large network is difficult due to memory constraints using even the most powerful machines. However, some tools allow a simulation to be distributed over a set of machines. Additionally, it may be desirable that a simulation behaves in accordance to a physical network (packet delay, traffic and network congestion, bandwidth limitations etc). These considerations also increase the overhead on the host machine. Subsequently, when choosing a network simulation tool for a given network, a distinction must be made between simulation tools which are suitable for low level networks and those which are suitable for P2P overlay networks. In respect to this decision, this document is split into two further sections. The first section describes simulation tools which are suitable for overlay networks, boasting scalability and small memory footprints. The second section describes some of the heavier network simulators, which boast an array of Internet models and are deemed more suitable for lower level network simulation. 2. Overlay Network Simulators 2.1. Narses The Narses simulator is a flow-based network simulator designed to avoid the overhead of packet level simulators [2] [3]. Narses is written in Java and achieves high levels of scalability by simulating aggregate flows rather than individual packets. By simulating a chunk of bytes and not individual packets, Narses reduces the number of events and subsequently the amount of memory used in the simulation. To further reduce memory requirements, Narses assumes that transfers between two end users are limited to the bandwidth allocated on the first link to the network. This ensures there is no need for intermediate routers and reassessment of link bandwidth, hence further reducing the number of events in the simulation. By taking such measures, Narses trades detail of the underlying network for decreased runtimes and a lower memory footprint. Of the models of Narses, the largest is the bandwidth-share model. This TCP like model tries to replicate the sharing of link bandwidth between independent flows. This model was tested in a network consisting of 600 nodes transmitting 200KB flows of data. Narses was reported to be 45 times faster and consumed 28% of the memory of NS2. There is no evidence of existing simulations of overlay networks for Narses. Download Simulator: http://sourceforge.net/projects/narses/ Brown Expires July 26, 2006 [Page 3] Internet-Draft Tools for P2P Network Simulation January 2006 2.2. 3LS 3LS (3-Level-Simulator) is a Java based simulator for overlay networks that uses a central step clock [3]. The system is separated into three models: 1. Networked 2. Protocol 3. User The network model is described in terms of distance between nodes in a 2D space. The protocol model is simply the P2P protocol being used. The user model generates input from users using a GUI or file. Communication can only be achieved between directly connected layers. When running the simulator it is possible to either create the models for each of the three described levels or to select existing models from a library. As the simulation runs, each event is displayed on the screen. Once completed, the simulation data is stored to a file and this data is accessed by a visualisation tool named AiSee [15]. Currently, an implementation of Gnutella 0.4 exists and has been tested on a small network of fewer than 20 nodes. Download Simulator: Please e-mail the creators Nyik San Ting and Ralph Deters (nyt431@mail.usask.ca, deters@cs.usask.ca) at the University of Saskatchewan for a copy. Documentation: [3] 2.3. NeuroGrid NeuroGrid [5][6] is a Java based network simulator designed for comparisons between file sharing P2P systems such as Gnutella, Freenet and other NeuroGrid systems. The NeuroGrid simulator is a single-threaded event simulator and uses a configuration file to define the protocol to simulate and the network properties. These properties include the number of nodes and queries to execute. Statistics including the number of successful queries and messages parsed can be saved into files for later analysis. Currently there are simulations available for Gnutella, NeuroGrid, Freenet and Pastry. NeruoGrid has been used to simulate networks up to 300,000 nodes on a machine with 4GB of RAM. Brown Expires July 26, 2006 [Page 4] Internet-Draft Tools for P2P Network Simulation January 2006 Download Simulator: http://sourceforge.net/projects/neurogrid/ Documentation: http://neurogrid.net/php/simulation.php 2.4. PeerSim PeerSim [7] is written in Java and offers an array of predefined * protocols for P2P simulation. These include: . OverStat: A collection of aggregation protocols. Aggregation is a collective term for a set of functions aimed at providing statistical information over distributed systems, such as the average load of the nodes or the size of the network. . SG-1: A protocol for self-organizing and maintaining a superpeer based topology. . T-Man: This protocol can be used to build a wide range of different topologies using only a ranking function that defines the preference of each node for neighbours. PeerSim is composed of two simulation engines, one is cycle-based and the other is event driven. This allows it to be both dynamic and scalable. The engines consist of components which may be 'plugged in' and use a simple ASCII file based configuration mechanism which helps reduce the overhead. The cycle-based engine does not model the transport layer and subsequently is more scalable. The event-based engine is less efficient but more realistic. PeerSim can achieve a network consisting of 10^6 nodes using the cycle-based engine. Download Simulator: http://sourceforge.net/projects/peersim/ Documentation: http://peersim.sourceforge.net/#docs, http://peersim.sourceforge.net/tutorial1/tutorial1.html 2.5. P2PSim P2PSim [10] is a written in C++ and designed for the evaluation of P2P protocols. This multi-threaded, discrete event simulator runs in several UNIX-like operating systems. P2PSim already supports Chord, Accordion, Koorde, Kelips, Tapestry, and Kademlia. These implementations are specific to P2PSim and do not model all features * Description of P2P protocols taken from [7] Brown Expires July 26, 2006 [Page 5] Internet-Draft Tools for P2P Network Simulation January 2006 of the protocols. P2PSim has been tested with up to 3000 nodes using the Chord implementation. Download Simulator: http://pdos.csail.mit.edu/p2psim/ 3. Packet level Network Simulators 3.1. Omnet++ OMNeT++ [8] is an open-source, component-based simulation environment with a strong focus on supporting the user with a Graphical User Interface (GUI). Although Omnet++ is not strictly a network simulator, it is gaining popularity in that domain. Components (modules) are programmed in C++ and assembled into larger components using a high level language (NED). It is primarily used for simulating communication networks, but can additionally be used for protocol modelling and modelling queuing networks and multiprocessors. Available models include but are not limited to IP, TCP, UDP, PPP, Ethernet, MPLS with LDP and RSVP-TE signalling and 802.11. Currently there exists a P2P swarming simulation for Omnet++ [16], which has been tested on a network of up to 1000 nodes. The overhead of modelling the transport layer in this simulation environment will likely hinder scalability. However, Omnet++ can also run distributed simulations over a number of machines. Download simulator: http://www.omnetpp.org/filemgmt/ Documentation: http://community.omnest.com/doc/tictoc-tutorial/ http://www.omnetpp.org/doc/manual/usman.html, http://www.omnetpp.org/doc/api/index.html 3.2. NS2 NS2 [9], developed at UC Berkeley, is a discrete event simulator targeted at networking research and provides substantial support for simulation of many Internet, routing, and multicast protocols. It can be installed on both Windows (using Cygwin) and Linux but evidently is more suited to Linux. NS2 is comprised of many various packages to provide its features (e.g. compatibility with numerous protocols and providing graphical representation of simulations etc) thus is notoriously difficult to use. NS2 implements a vast array of protocols including TCP and UDP, traffic source behavior such as FTP, Telnet, VBR and CBR. Additionally, there is router queue management mechanisms such as Brown Expires July 26, 2006 [Page 6] Internet-Draft Tools for P2P Network Simulation January 2006 Drop Tail, RED and CBQ implemented. NS2 also implements multicasting and some of the MAC layer protocols for LAN simulations. Currently, there is only one P2P simulation available for NS2 (Gnutella). Simulations in NS2 are constructed using a mixture of C++ and OTcl (Object Orientated version of Tcl created by MIT). Simulating in NS2 is a four step model. 1. Firstly, add a combination of C++ and OTcl code to the NS2 standard set of libraries to implement your protocol. 2. Create the simulated network using an OTcl script (define the nodes, links etc). 3. Run the generated scripts. 4. Analyze the trace files generated by NS2. A graphical model (NAM) can use the trace files to show a graphical representation of the simulation. Other tools available include graph plotting. Due to the realistic nature of the packet level NS2 simulator, scalability is a major issue. However, like most packet level simulators NS2 can run in parallel with a number of other machines. This can increase the maximum number of nodes for a given simulation but can become difficult to manage. Subsequently, NS2 is commonly used for simulating small networks and is generally unsuitable for modelling overlay networks. Download Simulator: http://www.isi.edu/nsnam/ns/ns-build.html Documentation: http://www.isi.edu/nsnam/ns/, http://nile.wpi.edu/NS/, http://www.isi.edu/nsnam/ns/ns-tutorial/index.html 3.3. SSFNet SSFNet [11] is a collection of Java and C++ based components and uses the Domain Modelling Language (DML) to configure networks as a series of configuration files. The principal classes in the SSF.OS Framework (for modelling of the host and OS components) and the SSF.Net Framework (for modelling the network connectivity) can be used to construct virtually any Internet model. The frameworks SSF.OS and SSF.Net hide all details of the discrete event simulator SSF API, which allows implementation of the protocols similar to a real operating system. This was the chosen simulator for Epichord [14]. Brown Expires July 26, 2006 [Page 7] Internet-Draft Tools for P2P Network Simulation January 2006 SSFNet simulations can be executed independently or in parallel with other simulations running on Linux, Windows or SUN Solaris alike. Regarding maximum network size, a network of 33,000 nodes is achievable (on a powerful machine with 2GB of RAM). SSFNet also has the ability to run a distributed simulation. Download Simulator: http://www.ssfnet.org/ssfImplementations.html Documentation: http://www.ssfnet.org/internetPage.html, http://www.ssfnet.org/SSFdocs/ssfapiManual.pdf 4. Summary The following tables summarizes the tools. SIMULATOR P2P PROTOCOLS MAX NODES DISTRIBUTED SIMULATION Narses None 600 No 3LS Gnutella < 1,000 No NeuroGrid Gnutella, NeuroGrid, 300,000 No Pastry, FreeNet PeerSim Collection of > 10^6 No internally developed P2P models P2PSim Chord, Accordion, 3,000 No Koorde, Kelips, Tapestry, Kademlia. Omnet++ None 1,000* Yes NS2 Gnutella N/A Yes SSFNet None 33,000 Yes Table 1. Simulator Characteristics Brown Expires July 26, 2006 [Page 8] Internet-Draft Tools for P2P Network Simulation January 2006 Max Nodes is the reported maximum based on information from the simulation developers, and refers to number of simulated nodes per host. This number may be hardware dependent. See the website for the tool for more details. P2P Protocols are those known to have modeled with the given tool and are models available with the downloaded tool. For Omnet++, this data was obtained from the P2P Swarming protocol [15]. This does not mean more nodes cannot be achieved using Omnet++. The following table shows the implementation language. SIMULATOR LANGUAGE Narses Java 3LS Java NeuroGrid Java PeerSim Java P2PSim C++ Omnet++ C++/NED NS2 C++/OTcl SSFNet Java/C++/DML Table 2. Implementation language(s) for each simulator 5. Security Considerations There are no new security considerations in this document. Brown Expires July 26, 2006 [Page 9] Internet-Draft Tools for P2P Network Simulation January 2006 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2] TJ Guili and Mary Barker, Narses: A scalable flow based network simulator, arXiv:cs.PF/0211024 v1 20 Nov 2002 [3] Narses Simulator, http://sourceforge.net/projects/narses/, viewed January 23, 2006. [4] Nyik San Ting, Ralph Deters, 3LS - A Peer-to-Peer Network Simulator, Third International Conference on Peer-to-Peer Computing (P2P 2003). [5] NeuroGrid, http://www.neurogrid.net, viewed January 23rd, 2006 [6] Sam Joseph and T. Hoshiai. Decentralized meta-data strategies: Effective peer-to-peer search. IEICE Transactions on Communications, E86-B(6):1740-1753, 2003. [7] PeerSim, http://peersim.sourceforge.net, viewed January 23, 2006. [8] Omnet++, http://www.omnetpp.org, viewed January 23, 2006. [9] Network Simulator 2, http://www.isi.edu/nsnam/ns/, viewed January 23, 2006. [10] P2PSim, http://pdos.csail.mit.edu/p2psim/, viewed January 23, 2006. [11] Scalable Simulation Framework Net, http://www.ssfnet.org, viewed January 23, 2006 [12] Kant, K., Iyer, R.: Modeling and simulation of ad-hoc/p2p file- sharing networks. In proceedings of Tools 2003. (2003) [13] Alberto Montresor, Gianni Di Caro, Poul E. Heegaard, BISON: Architecture of the Simulation Environment, IST-2001-38923 Brown Expires July 26, 2006 [Page 10] Internet-Draft Tools for P2P Network Simulation January 2006 [14] B. Leong, B. Liskov and E. D. Demaine: EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management, MIT Technical Report, Aug 2004. [15] AbsInt. AiSee homepage. http://www.aisee.com/, viewed January 24th, 2006 [16] Omnet ++ P2P Swarming Protocol, http://me55enger.net/swarm/, viewed January 24th, 2006. Author's Addresses Alan Brown Department of Computing Science and Mathematics University of Stirling Stirling FK9 4LA Scotland Email: abr@cs.stir.ac.uk Mario Kolberg Room 4B60, Cottrell Building Department of Computing Science and Mathematics University of Stirling Stirling FK9 4LA Scotland Email: mkolberg@ieee.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Brown Expires July 26, 2006 [Page 11] Internet-Draft Tools for P2P Network Simulation January 2006 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Brown Expires July 26, 2006 [Page 12] ------=_20060127180628_24746 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg ------=_20060127180628_24746-- From p2prg-bounces@ietf.org Fri Jan 27 13:43:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YZh-00071n-1B; Fri, 27 Jan 2006 13:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YZf-00071a-14 for p2prg@megatron.ietf.org; Fri, 27 Jan 2006 13:43:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03996 for ; Fri, 27 Jan 2006 13:42:21 -0500 (EST) From: buford@research.panasonic.com Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Yjr-00017G-39 for p2prg@ietf.org; Fri, 27 Jan 2006 13:54:28 -0500 Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k0RIhACS014686; Fri, 27 Jan 2006 13:43:10 -0500 Received: from localhost (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with SMTP id DC5DE1E8186; Fri, 27 Jan 2006 13:43:01 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62])by redwood.research.panasonic.com (Postfix) with ESMTP id 689E91E8184; Fri, 27 Jan 2006 13:43:01 -0500 (EST) Received: from [68.44.52.109] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Fri, 27 Jan 2006 13:43:10 -0500 To: Alan Brown , p2prg@ietf.org Message-ID: <214b81d4b6.1d4b6214b8@pintlmail.MITL.Research.Panasonic.COM> Date: Fri, 27 Jan 2006 13:43:10 -0500 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2Prg] Simulation tools for p2prg core subgroup X-Accept-Language: en Priority: normal Content-Type: multipart/mixed; boundary=--193d5ae86d19376d X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org This is a multi-part message in MIME format. ----193d5ae86d19376d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks Alan & Mario, I have added this to the subgroup's document list at: http://www.cs.uml.edu/~buford/irtf-p2prg/core.html John ----- Original Message ----- From: Alan Brown Date: Friday, January 27, 2006 1:06 pm Subject: [P2Prg] Simulation tools for p2prg core subgroup > Hi, > > For the core subgroup experimental work item, we have prepared the > attached draft summarizing existing free network simulation tools. > > If anyone has any comments or contributions they would like to > make, they > are most welcome. > > Thanks. > > -- > Alan Brown > PhD Research Student > Department of Computing Science and Mathematics > University of Stirling, FK9 4LA > Office: 4B49 > Tel: +441786 467449, > Web: http://www.cs.stir.ac.uk/~abr > -- > The University of Stirling is a university established in Scotland by > charter at Stirling, FK9 4LA. Privileged/Confidential Information may > be contained in this message. If you are not the addressee indicated > in this message (or responsible for delivery of the message to such > person), you may not disclose, copy or deliver this message to anyone > and any action taken or omitted to be taken in reliance on it, is > prohibited and may be unlawful. In such case, you should destroy this > message and kindly notify the sender by reply email. Please advise > immediately if you or your employer do not consent to Internet email > for messages of this kind. > > ----193d5ae86d19376d Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg ----193d5ae86d19376d Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg ----193d5ae86d19376d-- From p2prg-bounces@ietf.org Fri Jan 27 16:40:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bKq-0008He-08; Fri, 27 Jan 2006 16:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bKo-0008Ga-BQ for p2prg@megatron.ietf.org; Fri, 27 Jan 2006 16:40:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18670 for ; Fri, 27 Jan 2006 16:39:10 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2bIl-0007M6-Q4 for p2prg@ietf.org; Fri, 27 Jan 2006 16:38:41 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k0RLRToO004284; Fri, 27 Jan 2006 16:27:31 -0500 (EST) Received: from [192.168.1.201] ([132.250.218.64]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006012716273000737 ; Fri, 27 Jan 2006 16:27:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <214b81d4b6.1d4b6214b8@pintlmail.MITL.Research.Panasonic.COM> References: <214b81d4b6.1d4b6214b8@pintlmail.MITL.Research.Panasonic.COM> Date: Fri, 27 Jan 2006 16:27:29 -0500 To: buford@research.panasonic.com, Alan Brown , p2prg@ietf.org From: Brian Adamson Subject: Re: [P2Prg] Simulation tools for p2prg core subgroup Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org FYI, We have done some work in this area at NRL and have extended the ns-2 network simulator with a construct we call "AgentJ" that lets Java application code (with some minor tweaks) to execute in the ns-2 network simulation environment. We have been working with Cardiff University in Wales who have a p2p implementation entitled "P2PS" (Peer-to-Peer Simplified) that they have been using in some Grid Computing and work adapting Web Services to peer-to-peer networks. Using AgentJ, we have ported a version of P2PS into ns-2 The framework is still in progress and is being improved (we are conducting ongoing work with looking at p2p in MANET environments). It may be useful to the community and I can point interested parties to where to get the code. best regards, Brian Adamson At 1:43 PM -0500 1/27/06, buford@research.panasonic.com wrote: >Thanks Alan & Mario, >I have added this to the subgroup's document list at: > >http://www.cs.uml.edu/~buford/irtf-p2prg/core.html > >John > >----- Original Message ----- >From: Alan Brown >Date: Friday, January 27, 2006 1:06 pm >Subject: [P2Prg] Simulation tools for p2prg core subgroup > >> Hi, >> >> For the core subgroup experimental work item, we have prepared the >> attached draft summarizing existing free network simulation tools. >> >> If anyone has any comments or contributions they would like to >> make, they >> are most welcome. >> >> Thanks. >> >> -- >> Alan Brown >> PhD Research Student >> Department of Computing Science and Mathematics >> University of Stirling, FK9 4LA >> Office: 4B49 >> Tel: +441786 467449, >> Web: http://www.cs.stir.ac.uk/~abr >> -- >> The University of Stirling is a university established in Scotland by >> charter at Stirling, FK9 4LA. Privileged/Confidential Information may >> be contained in this message. If you are not the addressee indicated >> in this message (or responsible for delivery of the message to such >> person), you may not disclose, copy or deliver this message to anyone >> and any action taken or omitted to be taken in reliance on it, is >> prohibited and may be unlawful. In such case, you should destroy this >> message and kindly notify the sender by reply email. Please advise >> immediately if you or your employer do not consent to Internet email >> for messages of this kind. >> >> > >_______________________________________________ >P2prg mailing list >P2prg@irtf.org >https://www1.ietf.org/mailman/listinfo/p2prg > >_______________________________________________ >P2prg mailing list >P2prg@irtf.org >https://www1.ietf.org/mailman/listinfo/p2prg -- Brian Brian Adamson _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Sat Jan 28 23:04:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F33o1-000727-Hi; Sat, 28 Jan 2006 23:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F33nz-00070y-VC for p2prg@megatron.ietf.org; Sat, 28 Jan 2006 23:04:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29366 for ; Sat, 28 Jan 2006 23:03:00 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F33yF-00064s-Jx for p2prg@ietf.org; Sat, 28 Jan 2006 23:15:24 -0500 Received: from bufordw2 ([150.169.17.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id k0T44FZ8005743; Sat, 28 Jan 2006 23:04:15 -0500 From: "John Buford" To: Date: Sat, 28 Jan 2006 23:04:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [P2Prg] request for presentations at IETF65 on P2P Simulation Tools X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Given the wide set of tools for simulating P2P systems as described by Alan's and Mario's recent draft, we are proposing to have some presentations at the next P2PRG meeting at IETF 65 by researchers who are building such simulations. Goal would be to share mutual experiences with both existing and home-grown tools. Please respond to the list if either a) you are willing to give a presentation, b) you have suggestions about organizing this. John _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 31 10:50:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xmQ-0004BI-M8; Tue, 31 Jan 2006 10:50:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xL5-0002rH-R7 for p2prg@megatron.ietf.org; Tue, 31 Jan 2006 10:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25798 for ; Tue, 31 Jan 2006 10:20:49 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xVq-00078x-9i for p2prg@ietf.org; Tue, 31 Jan 2006 10:33:48 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k0VFMCoL014432; Tue, 31 Jan 2006 10:22:12 -0500 (EST) Received: from [132.250.92.235] ([132.250.92.235]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006013110221229060 ; Tue, 31 Jan 2006 10:22:12 -0500 Message-ID: <43DF80A4.2070701@nrl.navy.mil> Date: Tue, 31 Jan 2006 10:22:12 -0500 From: Ian User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: p2prg@ietf.org References: <200601281708.k0SH8cIN002315@mail1.nrl.navy.mil> In-Reply-To: <200601281708.k0SH8cIN002315@mail1.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Jan 2006 10:50:52 -0500 Cc: Subject: [P2Prg] Re: P2prg Digest, Vol 19, Issue 11 X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org I am one of the developers for AgentJ and I can volunteer to give a presentation on how we are using it in NS-2 to test peer-to-peer protocols for service discovery in wireless networks. This work is motivated by a need to discover resources in disadvantaged mobile ad-hoc networks. Presently, we are looking at P2P approaches to resource discovery and comparing them against various multicast techniques in a focused effort to produce middleware that conserves bandwidth and energy, reduces congestion and contention, and exhibits robustness to network fragmentation and node mobility. - that combined with Brian's email would be a good abstract for a presentation I could talk to during a P2PRG meeting in March. -Ian Downard >Date: Fri, 27 Jan 2006 16:27:29 -0500 >From: Brian Adamson >Subject: Re: [P2Prg] Simulation tools for p2prg core subgroup >To: buford@research.panasonic.com, Alan Brown , > p2prg@ietf.org >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >FYI, > >We have done some work in this area at NRL and have extended the ns-2 >network simulator with a construct we call "AgentJ" that lets Java >application code (with some minor tweaks) to execute in the ns-2 >network simulation environment. > >We have been working with Cardiff University in Wales who have a p2p >implementation entitled "P2PS" (Peer-to-Peer Simplified) that they >have been using in some Grid Computing and work adapting Web Services >to peer-to-peer networks. Using AgentJ, we have ported a version of >P2PS into ns-2 > >The framework is still in progress and is being improved (we are >conducting ongoing work with looking at p2p in MANET environments). >It may be useful to the community and I can point interested parties >to where to get the code. > >best regards, > >Brian Adamson > > > _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 31 11:26:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yKd-00035X-Pp; Tue, 31 Jan 2006 11:26:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yKb-00033j-VM for p2prg@megatron.ietf.org; Tue, 31 Jan 2006 11:26:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03338 for ; Tue, 31 Jan 2006 11:24:30 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yVS-0001gd-Iw for p2prg@ietf.org; Tue, 31 Jan 2006 11:37:27 -0500 Received: from bufordw2 ([150.169.17.5]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id k0VGPnI6008833; Tue, 31 Jan 2006 11:25:49 -0500 From: "John Buford" To: "Ian" , Date: Tue, 31 Jan 2006 11:25:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <43DF80A4.2070701@nrl.navy.mil> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Subject: [P2Prg] RE: P2prg Digest, Vol 19, Issue 11 X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Ian, Yes that would be a good presentation for the CORE subgroup work in the p2prg as well. John -----Original Message----- From: Ian [mailto:ian.downard@nrl.navy.mil] Sent: Tuesday, January 31, 2006 10:22 AM To: p2prg@ietf.org Cc: buford@research.panasonic.com Subject: Re: P2prg Digest, Vol 19, Issue 11 I am one of the developers for AgentJ and I can volunteer to give a presentation on how we are using it in NS-2 to test peer-to-peer protocols for service discovery in wireless networks. This work is motivated by a need to discover resources in disadvantaged mobile ad-hoc networks. Presently, we are looking at P2P approaches to resource discovery and comparing them against various multicast techniques in a focused effort to produce middleware that conserves bandwidth and energy, reduces congestion and contention, and exhibits robustness to network fragmentation and node mobility. - that combined with Brian's email would be a good abstract for a presentation I could talk to during a P2PRG meeting in March. -Ian Downard >Date: Fri, 27 Jan 2006 16:27:29 -0500 >From: Brian Adamson >Subject: Re: [P2Prg] Simulation tools for p2prg core subgroup >To: buford@research.panasonic.com, Alan Brown , > p2prg@ietf.org >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >FYI, > >We have done some work in this area at NRL and have extended the ns-2 >network simulator with a construct we call "AgentJ" that lets Java >application code (with some minor tweaks) to execute in the ns-2 >network simulation environment. > >We have been working with Cardiff University in Wales who have a p2p >implementation entitled "P2PS" (Peer-to-Peer Simplified) that they >have been using in some Grid Computing and work adapting Web Services >to peer-to-peer networks. Using AgentJ, we have ported a version of >P2PS into ns-2 > >The framework is still in progress and is being improved (we are >conducting ongoing work with looking at p2p in MANET environments). >It may be useful to the community and I can point interested parties >to where to get the code. > >best regards, > >Brian Adamson > > > _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg From p2prg-bounces@ietf.org Tue Jan 31 12:53:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zh6-0003ZR-GS; Tue, 31 Jan 2006 12:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zh0-0003Xi-BY for p2prg@megatron.ietf.org; Tue, 31 Jan 2006 12:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12776 for ; Tue, 31 Jan 2006 12:51:40 -0500 (EST) Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zrq-0005hv-9m for p2prg@ietf.org; Tue, 31 Jan 2006 13:04:39 -0500 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 1F204D33864; Tue, 31 Jan 2006 12:53:04 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 31 Jan 2006 12:53:04 -0500 X-Sasl-enc: 0rZzwwdmSNT8+Yq001hoKZd+SndcLCJiW6SXw/E6C0cm 1138729983 Received: from [192.168.0.3] (adsl-70-231-230-125.dsl.snfc21.sbcglobal.net [70.231.230.125]) by frontend2.messagingengine.com (Postfix) with ESMTP id 52DBC571483; Tue, 31 Jan 2006 12:53:01 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Message-Id: From: Bill Yeager Subject: Re: [P2Prg] RE: P2prg Digest, Vol 19, Issue 11 Date: Tue, 31 Jan 2006 09:53:01 -0800 To: "John Buford" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: p2prg@ietf.org, Ian X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1292983024==" Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org --===============1292983024== Content-Type: multipart/alternative; boundary=Apple-Mail-43--638492153 --Apple-Mail-43--638492153 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi John and Ian, Sounds like an excellent idea. bill On Jan 31, 2006, at 8:25 AM, John Buford wrote: > Ian, > Yes that would be a good presentation for the CORE > subgroup work in the p2prg as well. > John --Apple-Mail-43--638492153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John and Ian,

Sounds like an excellent = idea.=A0

bill

= On Jan 31, 2006, at 8:25 AM, John Buford wrote:

Ian,

Yes that would be a good presentation for the = CORE

subgroup work = in the p2prg as well.

John


= --Apple-Mail-43--638492153-- --===============1292983024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg --===============1292983024==--