idnits 2.17.1 draft-iab-p2p-archs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2009) is 5329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IAB G. Camarillo, Ed. 3 Internet-Draft IAB 4 Intended status: Informational September 23, 2009 5 Expires: March 27, 2010 7 Peer-to-peer (P2P) Architectures 8 draft-iab-p2p-archs-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 27, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 In this document we provide a survey of P2P (Peer-to-Peer) systems. 47 The survey includes a definition and several taxonomies of P2P 48 systems. This survey also includes a description of which types of 49 applications can be built with P2P technologies and examples of P2P 50 applications that are currently in use on the Internet. Finally, we 51 discuss architectural tradeoffs and provide guidelines for deciding 52 whether or not a P2P architecture would be suitable to meet the 53 requirements of a given application. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definition of a P2P System . . . . . . . . . . . . . . . . . . 3 59 2.1. Applying the P2P Definition to the DNS . . . . . . . . . . 5 60 2.2. Applying the P2P Definition to SIP . . . . . . . . . . . . 5 61 2.3. Applying the P2P Definition to P2PSIP . . . . . . . . . . 6 62 2.4. Applying the P2P Definition to BitTorrent . . . . . . . . 6 63 3. Functions in a P2P system . . . . . . . . . . . . . . . . . . 7 64 4. Taxonomies for P2P Systems . . . . . . . . . . . . . . . . . . 8 65 5. P2P Applications . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Content Distribution . . . . . . . . . . . . . . . . . . . 10 67 5.2. Distributed Computing . . . . . . . . . . . . . . . . . . 12 68 5.3. Collaboration . . . . . . . . . . . . . . . . . . . . . . 13 69 5.4. Platforms . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Architectural Tradeoffs and Guidance . . . . . . . . . . . . . 14 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 74 10. IAB Members at the Time of this Writing . . . . . . . . . . . 19 75 Appendix A. Historical Background on Distributed Architectures . 19 76 11. Informative References . . . . . . . . . . . . . . . . . . . . 21 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 1. Introduction 81 P2P (Peer-to-peer) systems have received a great deal of attention in 82 the last few years. A large number of scientific publications 83 investigate different aspects of P2P systems, several scientific 84 conferences explicitly focus on P2P networking, and there is an 85 Internet Research Task Force (IRTF) Research Group (RG) on P2P 86 systems (the Peer-to-Peer RG). There are also several commercial and 87 non-commercial applications that use P2P principles running on the 88 Internet. Some of these P2P applications are among the most widely 89 used applications on the Internet at present. 91 However, despite all the above, engineers designing systems or 92 developing protocol specifications do not have a common understanding 93 of P2P systems. More alarming is the fact that many people in the 94 telecom and datacom industries believe that P2P is synonymous with 95 illegal activity, such as the illegal exchange of content over the 96 Internet or P2P botnets. 98 The goal of this document is to discuss the tradeoffs involved in 99 deciding whether a particular application can be best designed and 100 implemented using a P2P paradigm or a different model (e.g., a 101 client-server paradigm). The document also aims to provide 102 architectural guidelines to assist in making such decisions. This 103 document provides engineers with a high-level understanding of what 104 defines a P2P system, what types of P2P systems exist, the 105 characteristics that can be expected from such systems, and what 106 types of applications can be implemented using P2P technologies. 107 Such understanding is essential in order to appreciate the tradeoffs 108 referred to above. In addition, we stress the importance of the fact 109 that P2P systems can be used to implement perfectly legitimate 110 applications and business models by providing several examples 111 throughout the document. 113 2. Definition of a P2P System 115 In order to discuss P2P systems, we first need a working definition 116 of a P2P system. In this section, we provide such a definition. All 117 discussions in this document apply to systems that comply with that 118 definition. In addition to providing examples of P2P systems, we 119 provide a few examples of systems that comply only partially with the 120 definition and, thus, cannot be strictly considered P2P systems. 121 Since these systems are not fully P2P compliant, some of the 122 discussions in this document may apply to them while others may not. 123 We have chosen to include those examples anyway to stress the fact 124 that P2P and centralized architectures are not completely disjoint 125 alternatives. There are many examples of systems that fall, for 126 instance, somewhere in between a pure P2P system and a centralized 127 one. 129 P2P is a term used in many contexts, sometimes with slightly 130 different meanings. It is possible to find several alternative 131 definitions, which are not all fully equivalent, in the existing 132 scientific literature. If we include other material (e.g., marketing 133 material) in our search for a definition on P2P, the diversity of 134 definitions is even higher. 136 The issue is that there is no clear border between a P2P paradigm and 137 other supposedly opposite paradigms such as client-server 138 [Milojicic2002]. In the extremes, some architectures are clearly P2P 139 while others are clearly client-server. However, there are 140 architectures that can be considered to be either or both, depending 141 on the definition for P2P being considered. Consequently, it is 142 important to understand what is common to all definitions of P2P and 143 what are the non-common traits some authors include in their own 144 definitions. 146 We consider a system to be P2P if the elements that form the system 147 share their resources in order to provide the service the system has 148 been designed to provide. The elements in the system both provide 149 services to other elements and request services from other elements. 151 In principle, all the elements in the system should meet the previous 152 criteria for the system to be considered P2P. However, in practice, a 153 system can have a few exceptions (i.e., a few nodes that do not meet 154 the criteria) and still be considered P2P. For example, a P2P system 155 can still be considered P2P even if it has a centralized enrollment 156 server. On the other hand, some systems divide endpoints between 157 peers and clients. Peers both request and provide services while 158 clients generally only request services. A system where most 159 endpoints behaved as clients could not strictly be considered P2P. 161 Although most definitions do not state it explicitly, many implicitly 162 assume that for a system to be P2P, its nodes need to be involved in 163 transactions that are related to services that do not directly 164 benefit the nodes. 166 Some authors add that the elements that form the P2P system, which 167 unsurprisingly are called peers, should be able to communicate 168 directly between them without passing intermediaries 169 [Schollmeier2001]. Other authors add that the system should be self 170 organizing and have decentralized control [Roussopoulus2004]. 172 Note that the previous definitions are given within the context of a 173 single individual service. A complex service can be made up of 174 several individual services. Some of these individual services can 175 consist of P2P services and some of them can consist of client-server 176 services. For example, a file sharing client may include a P2P 177 client to perform the actual file sharing and a web browser to access 178 additional information on a centralized web server. Additionally, 179 there are architectures where a client-server system can serve as a 180 fall back for a service normally provided by a P2P system, or vice 181 versa. 183 Providing a service typically involves processing or storing data. 184 According to our definition, in a P2P system, peers share their 185 processing and storage capacity (i.e., their hardware and software 186 resources) so that the system can provide a service. For example, if 187 the service to be provided is a file distribution service, different 188 peers within the system will store different files. When a given 189 peer wants to get a particular file, the peer will first discover 190 which peer or peers have that file and then obtain the file from 191 those peers. 193 The definition for P2P provides us with a criterion to decide whether 194 or not a system is P2P. As examples, in the following sections we 195 apply the definition to the DNS, SIP, P2PSIP, and BitTorrent and 196 discuss which of these systems are P2P. 198 2.1. Applying the P2P Definition to the DNS 200 The DNS is a hierarchical distributed system that has sometimes been 201 classified as a hierarchical client-server system and sometimes as a 202 P2P system [Milojicic2002]. According to our definition, the DNS is 203 not a P2P system because DNS resolvers are service requesters but not 204 service providers. The elements in a system need to be both service 205 requesters and service providers for the system to be considered P2P. 207 2.2. Applying the P2P Definition to SIP 209 SIP [RFC3261] is a rendezvous protocol that allows a user to locate a 210 remote user and establish a communication session with that remote 211 user. Once the remote user is located, sessions are established in a 212 similar way in all SIP systems; directly between the nodes involved 213 in the session. However, the rendezvous function can be implemented 214 in different ways: the traditional SIP way and the P2P way. This 215 section discusses the former. Section 2.3 discusses the latter. 217 In traditional SIP, a central server is typically responsible for a 218 DNS domain. User agents in the domain register with the server. 219 This way, when a user agent wants to communicate with a remote user 220 agent in the same domain, the user agent consults the server, which 221 returns the contact information of the remote user agent. Session 222 establishment occurs directly between the user agents, without the 223 involvement of the server. 225 Inter-domain communications in SIP are implemented using server 226 federations. The servers responsible for each domain form a 227 federation in which they can communicate with each other. This way, 228 when a user agent wants to communicate with a remote user agent in a 229 different domain, the user agent consults its local server, which in 230 turn consults the server responsible for the remote user agent's 231 domain. 233 SIP user agents act as both clients and servers. A given user agent 234 can act as a client in a particular transaction and as a server in a 235 subsequent transaction. However, traditional SIP cannot be 236 considered a P2P system because user agents only share their 237 resources for their own benefit. That is, a given user agent is only 238 involved in transactions related to a service that benefits (somehow) 239 the user agent itself. For example, any given user agent is only 240 involved in SIP INVITE transactions (which are used to establish 241 sessions) intended to establish sessions that involve the user agent. 242 For a system to be P2P, its nodes need to be involved in transactions 243 that benefit others. That is, transactions that are related to 244 services that do not benefit directly the nodes. 246 2.3. Applying the P2P Definition to P2PSIP 248 In addition to the traditional way of using SIP, SIP can also be used 249 in a way that is generally referred to as P2PSIP (P2PSIP is the name 250 of the IETF working group developing the technology). In P2PSIP, 251 user agents do not register their contact information with a central 252 server. Instead, they register it with an overlay formed by the user 253 agents in the system. This way, when a user agent wants to 254 communicate with a remote user agent, the user agent consults the 255 overlay, which returns the contact information of the remote user 256 agent. Session establishment occurs, as usual, directly between the 257 user agents. P2PSIP is a P2P system because nodes share their 258 resources by storing data that is not related to them (i.e., contact 259 information of different user agents) and are involved in 260 transactions that are related to services that do not revert directly 261 to the nodes themselves (e.g., the rendezvous of two remote user 262 agents). 264 2.4. Applying the P2P Definition to BitTorrent 266 BitTorrent [BitTorrent] is a protocol used to distribute files. The 267 group of endpoints involved in the distribution of a particular file 268 is called a swarm. The file is divided into several pieces. An 269 endpoint interested in the file needs to download all the pieces of 270 the file from other endpoints in the swarm. Endpoints downloading 271 pieces of the file also upload pieces they already have to other 272 endpoints in the swarm. An endpoint that both downloads (because it 273 does not have the complete file yet) and uploads pieces is called a 274 leecher (note that this definition is counterintuitive because, in 275 other contexts, a leecher normally means someone that takes but does 276 not give). When an endpoint has the whole file (i.e., it has all the 277 pieces of the file) it does not need to download any pieces any 278 longer. Therefore, it only uploads pieces to other endpoints. Such 279 an endpoint is called a seeder. 281 BitTorrent systems are P2P systems because endpoints request services 282 from other endpoints (i.e., download pieces from other endpoints) and 283 provide services to other endpoints (i.e., upload pieces to other 284 endpoints). Note, however, that a particular swarm where most 285 endpoints were infrastructure nodes that had the complete file from 286 the beginning and, thus, acted all the time as seeders could not be 287 strictly considered a P2P system because most endpoints would only be 288 providing services, not requesting them. 290 3. Functions in a P2P system 292 P2P systems include several functions. The following functions are 293 independent of the service provided by the P2P system. They handle 294 how peers connect to the system. 296 o Enrollment function: nodes joining a P2P system need to obtain 297 valid credentials to join the system. The enrollment function 298 handles node authentication and authorization. 299 o Peer discovery function: in order to join a P2P system (i.e., to 300 become a peer), a node needs to establish a connection with one or 301 more peers that are already part of the system. The peer 302 discovery function allows nodes to discover peers in the system in 303 order to connect to them. 305 The functions above are provided in a centralized way in some P2P 306 systems (e.g., through a central enrollment server and a central peer 307 discovery server, which is sometimes called a bootstrap server). 308 Taxonomies for P2P systems, which will be discussed in Section 4, do 309 not consider these functions when classifying P2P systems. Instead, 310 they classify P2P systems based on how the following set of functions 311 are implemented. 313 The following functions depend on the service provided by the P2P 314 system. That is, not all P2P systems implement all functions. For 315 example, a P2P system used only for storing data may not implement 316 the computing function. In another example, a P2P system used only 317 for computing may not implement the data storage function. Also, 318 some of these functions are implemented in a centralized way in some 319 P2P systems. 321 o Data indexing function: it deals with indexing the data stored in 322 the system. 323 o Data storage function: it deals with storing and retrieving data 324 from the system. 325 o Computation function: it deals with the computing performed by the 326 system. Such computing can be related to, among other things, 327 data processing or real-time media processing. 328 o Message transport function: it deals with message exchanges 329 between peers. Depending on how this function is implemented, 330 peers can exchange protocol messages through a central server, 331 directly between them, or through peers that provide overlay 332 routing. 334 Depending on the service being provided, some of the functions above 335 may not be needed. Section 5 discusses different types of P2P 336 applications, which implement different services. 338 4. Taxonomies for P2P Systems 340 Taxonomies classify elements into groups so that they can be studied 341 more easily. People studying similar elements can focus on common 342 problem sets. Taxonomies also provide common terminology useful when 343 discussing issues related to individual elements and groups of 344 elements within a given taxonomy. In this section, we provide a few 345 taxonomies for P2P systems in order to facilitate their study and to 346 present such a common terminology. 348 Given that different authors cannot seem to agree on a single common 349 definition for P2P, it should not come as a surprise the fact that 350 there are also many different taxonomies of P2P systems. While 351 classifying P2P systems according to different traits is something 352 normal, the fact that different authors use the same term to indicate 353 different things (e.g., first and second generation P2P systems mean 354 different things for different authors) sometimes confuses readers. 356 Arguably, the most useful classification of P2P systems has to do 357 with the way data is indexed. That is, how the data indexing 358 function is implemented. A P2P index can be centralized, local, or 359 distributed [RFC4981]. With a centralized index, a central server 360 keeps references to the data in all peers. With a local index, each 361 peer only keeps references to its own data. With a distributed 362 index, references to data reside at several nodes. Napster, early 363 versions of Gnutella (up to version 0.4), and Distributed Hash Table 364 (DHT)-based systems are examples of centralized, local, and 365 distributed indexes, respectively. 367 Indexes can also be classified into semantic and semantic-free. A 368 semantic index can capture relationships between documents and their 369 metadata whereas a semantic-free index cannot [RFC4981]. While 370 semantic indexes allow for richer searches, they sometimes (depending 371 on their implementation) fail to find the data even if the data is 372 actually in the system. 374 Some authors classify P2P systems by their level of decentralization. 375 Hybrid P2P systems need a central entity to provide their services 376 while pure P2P systems can continue to provide their services even if 377 any single peer is removed from the system [Schollmeier2001]. 378 According to this definition, P2P systems with a centralized index 379 are hybrid P2P systems while systems with local and distributed 380 indexes are pure P2P systems. 382 Still, some authors classify pure P2P systems by the level of 383 structure they show [Alima2005]. In unstructured systems, peers join 384 the system by connecting themselves to any other existing peers. In 385 structured systems, peers join the system by connecting themselves to 386 well-defined peers based on their logical identifiers. The 387 distinction between early unstructured systems (e.g., early versions 388 of Gnutella), which used local indexes and had no structure at all, 389 and structured systems (e.g., DHT-based systems), which used 390 distributed indexes and had a well-defined structure, was fairly 391 clear. However, unstructured systems have evolved and now show a 392 certain level of structure (e.g., some systems have special nodes 393 with more functionality) and use distributed indexes. Therefore, the 394 border between unstructured and structured is somewhat blurry. 396 Some authors refer to different generations of P2P systems. For 397 some, the first, second, and third generations consist of P2P systems 398 using centralized indexes, flooding-based searches (i.e., using local 399 indexes), and DHTs (i.e., DHT-based distributed indexes), 400 respectively [Foster2003]. Other authors consider that second 401 generation systems can also have non-DHT-based distributed indexes 402 [Zhang2006]. Yet for other authors, the first and second generations 403 consist of P2P systems using unstructured (typically using flooding- 404 based searched) and structured (e.g., DHT-based) routing, 405 respectively [RFC4981]. Talking about generations of P2P systems in 406 a technical context is not useful (as stated previously, it is more 407 useful to classify systems based on how they index data) because 408 different generations are defined in different ways depending on the 409 author and because talking about generations gives the impression 410 that later generations are better than earlier ones. Depending on 411 the application to be implemented, a P2P system of an earlier 412 generation may meet the application's requirements in a better way 413 than a system of a later generation. 415 As discussed in Section 3, the previous taxonomies do not consider 416 the enrollment and the peer discovery functions. For example, a pure 417 P2P system would still be considered pure even if it had centralized 418 enrollment and peer discovery servers. 420 5. P2P Applications 422 P2P applications developed so far can be classified into the 423 following domains [Pourebrahimi2005] [Milojicic2002]: content 424 distribution, distributed computing, collaboration, and platforms. 426 5.1. Content Distribution 428 When most people think of P2P, they think of file sharing. Moreover, 429 they think of illegal file sharing where users exchange material 430 (e.g., songs, movies, and software in digital format) they are not 431 legally authorized to distribute. However, despite people's 432 perception, P2P file sharing systems are not intrinsically illegal. 434 P2P file sharing applications provide one out of many means to store 435 and distribute content on the Internet. HTTP [RFC2616] and FTP 436 [RFC0959] servers are examples of other content distribution 437 mechanisms. People would not claim that HTTP is an illegal mechanism 438 just because a number of users upload material that cannot be legally 439 distributed to an HTTP server where other users can download it. The 440 same way, it is misleading to claim that P2P is illegal just because 441 some users use it for illegal purposes. 443 P2P content distribution systems are used to implement legitimate 444 applications and business models that take advantage of the 445 characteristics of these P2P systems. Examples of legitimate uses of 446 these systems include the distribution of pre-recorded TV programs 447 [Rodriguez2005], Linux distributions [Rodriguez2005], game updates 448 [WoW], and live TV [Peltotalo2008] [Octoshape] by parties legally 449 authorized to distribute that content (e.g., the content owner). 451 The main advantage of P2P content distribution systems is their 452 scalability. In general, the more popular the content handled, the 453 more scalable the P2P system is. The peer that has the original 454 content (i.e., the owner of a file or the source of an audio or video 455 stream) distributes it to a fraction of the peers interested in the 456 content and these peers in turn distribute it to other peers also 457 interested in the content. Note that, in general, there is no 458 requirement for peers distributing content to be able to access it 459 (e.g., the content may be encrypted so that peers without the 460 decryption key are content distributors but not content consumers). 461 Peers can distribute content to other peers in different ways. For 462 example, they can distribute the whole content, pieces of the content 463 (i.e., swarming), or linear combinations of pieces of content 464 [Gkantsidis2005]. In any case, the end result is that the peer with 465 the original content does not need to distribute the whole content to 466 all the peers interested in it, as it would be the case when using a 467 centralized server. Therefore, the capacity of the system is not 468 limited by the processing capacity and the bandwidth of the peer with 469 the original content and, thus, the quality of the whole service 470 increases. 472 An important area that determines the characteristics of a P2P 473 distribution system is its peer selection process. Interestingly, 474 the different parties involved in the distribution have different 475 views on how peers should be selected. Users are interested in 476 connecting to peers that have the content they want and also have 477 high bandwidth and processing capacity, and low latency so that 478 transfers are faster. The Content Delivery Network (CDN) operator 479 wants peers to connect first to the peers who have the rarest pieces 480 of the content being distributed in order to improve the reliability 481 of the system (in case those peers with the rare pieces of content 482 leave the system). Network operators prefer peers to perform local 483 transfers within their network so that their peering and transit 484 agreements are not negatively affected (i.e., by downloading content 485 from a remote network despite of the content being available 486 locally). Sometimes, all these requirements can be met at the same 487 time (e.g., a peer with a rare piece of content has high bandwidth 488 and processing capacity and is in the local network). However, other 489 times the system can just try and reach acceptable tradeoffs when 490 selecting peers. These issues were the subject of the IETF P2P 491 Infrastructure (P2PI) workshop held in 2008. 493 Network operators also find that, depending on the dimensioning of 494 their networks (e.g., where the bottlenecks are), the different 495 traffic patterns generated by P2P or centralized CDNs can be more or 496 less easily accommodated by the network [Huang2007]. 498 An example of a sensor network based on P2P content distribution and 499 Delay-tolerant Networking (DTL) is ZebraNet [Juang2002]. ZebraNet is 500 a network used to track Zebras in the wild. Each zebra carries a 501 tracking collar that gathers data about the zebra (e.g., its 502 position) at different times. Mobile stations communicate wirelessly 503 with the collars in order to gather and consolidate data from 504 different zebras. Since not all the zebras get close enough to a 505 mobile station for their collars to be able to communicate with the 506 station, the collars communicate among them exchanging the data they 507 have gathered. In this way, a given collar provides the mobile 508 station with data from different zebras, some of which may never get 509 close enough to the mobile station. P2P networks are especially 510 useful in situations where it is impossible to deploy a communication 511 infrastructure (e.g., due to national park regulations or potential 512 vandalism) such as in the previous example or when tracking reindeers 513 in Lapland [SNC] (this project has focused on DTNs more than on P2P 514 so far but some of its main constraints are similar to the ones in 515 ZebraNet). Note however that sensor networks such as ZebraNet cannot 516 be strictly considered P2P because the only node issuing service 517 requests (i.e., the only node interested in receiving data) is a 518 central node (i.e., the mobile station). 520 5.2. Distributed Computing 522 In P2P distributed computing, each task is divided into independent 523 subtasks that can be completed in parallel (i.e., no inter-task 524 communication) and delivered to a peer. The peer completes the 525 subtask using its resources and returns the result. When all the 526 subtasks are completed, their results are combined to obtain the 527 result of the original task. 529 Peers in P2P distributed computing systems are typically distributed 530 geographically and are connected among them through wide-area 531 networks. Conversely, in cluster computing, nodes in a cluster are 532 typically physically close to each other (often in the same room) and 533 have excellent communication capabilities among them. Consequently, 534 computer clusters can divide tasks into subtasks that are not 535 completely independent from one another and that cannot be completed 536 in parallel. The excellent communication capabilities among the 537 nodes in the cluster make it possible to synchronize the completion 538 of such tasks. Since computers in a cluster are so tightly 539 integrated, cluster computing techniques are not typically considered 540 P2P networking. 542 The main advantage of P2P distributed computing systems is that a 543 number of regular computers can deliver the performance of a much 544 more powerful (and typically expensive) computer. Nevertheless, at 545 present P2P distributed computing can only be applied to tasks that 546 can be divided into independent subtasks that can be completed in 547 parallel. Tasks that do not show this characteristic are better 548 performed by a single powerful computer. 550 Note that even though distributed computing in general can be 551 considered P2P (which is why we have included it in this section as 552 an example of a P2P application), most current systems whose main 553 focus is distributed computing do not fully comply with the 554 definition for P2P provided in Section 2. The reason is that, in 555 those systems, service requests are typically generated only by a 556 central node. That is, most nodes do not generate service requests 557 (i.e., create tasks). This is why Grid computing [Foster1999] cannot 558 be strictly considered P2P [Lua2005]. Another well-known example 559 that cannot strictly be considered P2P either is SETI@home (Search 560 for Extra-Terrestrial Intelligence) [Seti], where the resources of 561 many computers are used to analyze radio telescope data. MapReduce 562 [Dean2004], a programming model for processing large data sets cannot 563 strictly be considered P2P either for the same reason. On the other 564 hand, a number of collaboration applications implement distributed 565 computing functions in a P2P way (see Section 5.3). 567 Another form of distributed computing that cannot be strictly 568 considered P2P (despite its name) are P2P botnets [Grizzard2007]. In 569 P2P botnets, service requests, which usually consist of generating 570 spam or launching Distributed Denial of Service (DDoS) attacks, are 571 typically generated by a central node (or a few central nodes). That 572 is why they cannot be strictly considered P2P. An example of this 573 type of P2P botnet that propagates using a DHT-based overlay is the 574 Storm botnet [Kanich2008]. In addition to their distributed 575 propagation techniques, some P2P botnets also use a distributed 576 command and control channel, which makes it more difficult to combat 577 them than traditional botnets using centralized channels [Cooke2005]. 578 DHT-based overlays can also be used to support the configuration of 579 different types of radio access networks [Oechsner2006]. 581 5.3. Collaboration 583 P2P collaboration applications include communication applications 584 such as Voice over IP (VoIP) and Instant Messaging (IM) applications. 585 Section 2.3 included discussions on P2PSIP systems, which are an 586 example of a standard-based P2P collaboration application. There are 587 also proprietary P2P collaboration applications on the Internet 588 [Skype]. Collaboration applications typically provide rendezvous, 589 NAT traversal, and a set of media-related functions (e.g., media 590 mixing or media transcoding). Note that some of these functions 591 (e.g., media transcoding) are, effectively, a form of distributed 592 computing. 594 P2P rendezvous systems are especially useful in situations where 595 there is no infrastructure. A few people with no Internet 596 connectivity setting up an ad-hoc system to exchange documents or the 597 members of a recovery team communicating among themselves in a 598 disaster area are examples of such situations. P2PSIP is sometimes 599 referred to as infrastructureless SIP to distinguish it from 600 traditional SIP, which relies on a rendezvous server infrastructure. 602 5.4. Platforms 604 P2P platforms can be used to build applications on top of them. They 605 provide functionality applications on top of them can use. An 606 example of such a platform is JXTA [Gong2001]. JXTA provides peer 607 discovery, grouping of peers, and communications between peers. The 608 goal with these types of P2P platforms is that they become the 609 preferred environment for application developers. They take 610 advantage of the good scalability properties of P2P systems. 612 6. Architectural Tradeoffs and Guidance 614 In this document, we have provided a brief overview of P2P 615 technologies. In order to dispel the notion that P2P technologies 616 can only be used for illegal purposes, we have discussed a number of 617 perfectly legitimate applications that have been implemented using 618 P2P. Examples of these applications include video conferencing 619 applications [Skype], the distribution of pre-recorded TV programs 620 [Rodriguez2005], Linux distributions [Rodriguez2005], game updates 621 [WoW], and live TV [Peltotalo2008] [Octoshape] by parties legally 622 authorized to distribute that content. 624 When deciding whether or not to use a P2P architecture to implement a 625 given application, it is important to consider the general 626 characteristics of P2P systems and evaluate them against the 627 application's requirements. It is not possible to provide any 628 definitive rule to decide whether or not a particular application 629 would be implemented best using P2P. Instead, we discuss a set of 630 tradeoffs to be considered when making architectural decisions and 631 provide guidance on which types of requirements are better met by a 632 P2P architecture (security-related aspects are discussed in 633 Section 7). Ultimately, applications' operational requirements need 634 to be analyzed on a case-by-case basis in order to decide the most 635 suitable architecture. 637 P2P systems are a good option when there is no existing 638 infrastructure and deploying it is difficult for some reason. Ad-hoc 639 systems are usually good candidates to use P2P architectures. 640 Disaster areas where existing infrastructures have been destroyed or 641 rendered unusable can also benefit from P2P systems. 643 One of the main features of P2P systems is their scalability. Since 644 the system can leverage the processing and storage capacity of all 645 the peers in the system, increases in the system's load are tackled 646 by having the peers use more of their processing or storage capacity. 647 Adding new peers generally increases the system's load but also 648 increases the system's processing and storage capacity. That is, 649 there is no typically need to update any central servers to be able 650 to deal with more users or more load [Leibniz2007]. Adaptive P2P 651 systems tune themselves in order to operate in the best possible mode 652 when conditions such as number of peers or churn rate change 653 [Mahajan2003]. In any case, at present, maintaining a running DHT 654 requires nontrivial operational efforts [Rhea2005]. 656 Robustness and reliability are important features in many systems. 657 For many applications to be useful, it is essential that they are 658 dependable [RFC4981]. While there are many techniques to make 659 centralized servers highly available, peers in a P2P system are not 660 generally expected to be highly available (of course, it is also 661 possible to build a more expensive P2P system with only highly 662 available peers). P2P systems are designed to cope with peers 663 leaving the system ungracefully (e.g., by crashing). P2P systems use 664 techniques such as data replication and redundant routing table 665 entries to improve the system's reliability. This way, if a peer 666 crashes, the data it stored is not lost and can still be found in the 667 system. 669 The performance of a P2P system when compared to a server-based 670 system depends on many factors (e.g., the dimensioning of the server- 671 based system). One of the most important factors is the type of task 672 to be performed. As we discussed in Section 5.2, if the task that 673 needs to be computed can be divided into independent subtasks that 674 can be completed in parallel, a P2P distributed-computing system made 675 up of regular computers may be able to perform better than even a 676 super computer. If the task at hand consists of completing database 677 queries, a well-dimensioned centralized database may be faster than a 678 DHT. 680 The performance of a P2P system can be negatively affected by a lack 681 of cooperation between the peers in the system. It is important to 682 have incentives in place in order to minimize the number of free 683 riders in the system. Incentive systems generally aim to take the 684 P2P system to optimal levels of cooperation [Feldman2004]. 686 There are tradeoffs between the scalability, robustness, and 687 performance of a particular P2P system that can be influenced through 688 the configuration of the system. For example, a P2P database system 689 where each peer stored all the information in the system would be 690 robust and have a high performance (i.e., queries would be completed 691 quickly) but would not be efficient or scalable. If the system 692 needed to grow, it could be configured so that each node stored only 693 a part of the information of the whole system in order to increase 694 its efficiency and scalability at the expense of its robustness and 695 performance. 697 Energy consumption is another important property of a system. Even 698 though the overall consumption of a client-server system is generally 699 lower than that of a P2P system providing the same service, P2P 700 systems avoid central servers (e.g., server farms) that can 701 potentially concentrate the consumption of high amounts of energy in 702 a single geographical location. When the nodes in a system need to 703 be up and running all the time anyway, it is possible to use those 704 nodes to perform tasks in a P2P way. However, using battery-powered 705 devices as peers in a P2P system presents some challenges because a 706 peer typically consumes more energy than a client in a client-server 707 architecture where they can go into sleep mode more often 708 [Kelenyi2008]. Energy-aware P2P protocols may be the solution to 709 these challenges [Gurun2006]. 711 This section has discussed a set of important system properties and 712 compared P2P and centralized systems with respect to those 713 properties. However, the most important factor to take into 714 consideration is often cost. Both capital and operating costs need 715 to be taken into account when evaluating the scalability, 716 reliability, and performance of a system. If updating a server so 717 that it can tackle more load is inexpensive, a server-based 718 architecture may be the best option. If a highly-available server is 719 expensive, a P2P system may be the best choice. With respect to 720 operating costs, as previously stated, at present, maintaining a 721 running DHT requires nontrivial operational efforts [Rhea2005]. 723 In short, even though understanding the general properties of P2P and 724 server-based systems is important, deciding which architecture fits 725 best a particular application involves obtaining detailed information 726 about the application and its context. In most scenarios, there are 727 no easy rules that tell us when to use which architecture. 729 7. Security Considerations 731 Security is an important issue that needs to be considered when 732 choosing an architecture to design a system. The first issue that 733 needs to be considered is to which extent the nodes in the system can 734 be trusted. If all the nodes in the system are fully trusted (e.g., 735 all the nodes are under the full control of the operator of the 736 system and will never act in a malicious or otherwise incorrect way), 737 a P2P architecture can achieve a high level of security. However, if 738 nodes are not fully trusted and can be expected to behave in 739 malicious ways (e.g., launching active attacks), providing an 740 acceptable level of security in a P2P environment becomes 741 significantly more challenging than in a non-P2P environment because 742 of its distributed ownership, and lack of centralized control and 743 global knowledge [Mondal2006]. Ultimately, the level of security 744 provided by a P2P system largely depends on the proportion of its 745 nodes that behave maliciously. Providing an acceptable level of 746 security in a P2P system with a large number of malicious nodes can 747 easily become impossible. 749 P2P systems can be used by attackers to harvest IP addresses in use. 750 Attackers can passively obtain valid IP addresses of potential 751 victims without performing active scans because a given peer is 752 typically connected to multiple peers. In addition to being passive, 753 this attack is much more efficient than performing scans when the 754 address space to be scanned is large and sparsely populated (e.g., 755 the current IPv6 address space). Additionally, in many cases there 756 is a high correlation between a particular application and a 757 particular operating system. In this way, an attacker can harvest IP 758 addresses suitable to launch attacks that exploit vulnerabilities 759 that are specific to a given operating system. 761 Central elements in centralized architectures become an obvious 762 target for attacks. P2P systems minimize the amount of central 763 elements and, thus, are more resilient against attacks targeted only 764 at a few elements. 766 When designing a P2P system, it is important to consider a number of 767 threats that are specific to P2P systems. Additionally, more general 768 threats that apply to other architectures as well are sometimes 769 bigger in a P2P environment. P2P-specific threats mainly focus on 770 the data storage functions and the routing of P2P systems. 772 In a P2P system, messages (e.g., service requests) between two given 773 peers generally traverse a set of intermediate peers that help route 774 messages between the two peers. Those intermediate peers can attempt 775 to launch on-path attacks they would not be able to launch if they 776 were not on the path between the two given peers. An attacker can 777 attempt to choose a logical location in the P2P overlay that allows 778 it to launch on-path attacks against a particular victim or a set of 779 victims. The Sybil [Douceur2002] attack is an example of such an 780 attack. The attacker chooses its overlay identifier so that it 781 allows the attacker to launch future attacks. This type of attack 782 can be mitigated by controlling how peers obtain their identifiers 783 (e.g., by having a central authority). 785 A trivial passive attack by peers routing messages consists of trying 786 to access the contents of those messages. Encrypting message parts 787 that are not required for routing is an obvious defence against this 788 type of attack. 790 An attacker can create a message and claim that it was actually 791 created by another peer. The attacker can even take a legitimate 792 message as a base and modify it to launch the attack. Peer and 793 message authentication techniques can be used to avoid this type of 794 attack. 796 Attackers can attempt to launch a set of attacks against the storage 797 function of the P2P system. The following are generic (i.e., non-P2P 798 specific) attacks. Even if they are generic attacks, the way to 799 avoid or mitigate them in a P2P system can be more challenging than 800 in other architectures. 802 An attacker can attempt to store too much data in the system. A 803 quota system that can be enforced can be used to mitigate this 804 attack. 806 Unauthorized peers can attempt to perform operations on data objects. 807 Peer authorization in conjunction with peer authentication avoids 808 unauthorized operations. 810 A peer can return forged data objects claiming they are legitimate. 811 Data object authentication prevents this attack. However, a peer can 812 return a previous version of a data object and claim it is the 813 current version. The use of lifetimes can mitigate this type of 814 attack. 816 The following are P2P-specific attacks against the data storage 817 function of a P2P system. An attacker can refuse to store a 818 particular data object. An attacker can also claim a particular data 819 object does not exist even if another peer created it and stored it 820 on the attacker. These DoS (Denial of Service) attacks can be 821 mitigated by using data replication techniques and performing 822 multiple, typically parallel, searches. 824 Attackers can attempt to launch a set of attacks against the routing 825 of the P2P system. An attacker can attempt to modify the routing of 826 the system in order to be able to launch on-path attacks. Attackers 827 can use forged routing maintenance messages for this purpose. The 828 Eclipse attack [Singh2006] is an example of such an attack. 829 Enforcing structural constraints or enforcing node degree bounds can 830 mitigate this type of attack. 832 It is possible to launch DoS attacks by modifying or dropping routing 833 maintenance messages or by creating forged ones. Having nodes get 834 routing tables from multiple peers can help mitigate this type of 835 attack. 837 Attackers can launch a DoS attack by creating churn. By leaving and 838 joining a P2P overlay rapidly many times, a set of attackers can 839 create large amounts of maintenance traffic and make the routing 840 structure of the overlay unstable. Limiting the amount of churn per 841 node is a possible defence against this attack. 843 8. IANA Considerations 845 There are no IANA actions associated with this document. 847 9. Acknowledgements 849 Jouni Maenpaa and Jani Hautakorpi helped with the literature review. 850 Henning Schulzrinne provided useful ideas on how to define P2P 851 systems. Bruce Lowekamp, Dan Wing, Dan York, Enrico Marocco, Cullen 852 Jennings, and Frank Uwe Andersen provided useful comments on this 853 document. Loa Andersson, Aaron Falk, Barry Leiba, Kurtis Lindqvist, 854 Dow Street, and Lixia Zhang participated in the IAB discussions on 855 this document. 857 10. IAB Members at the Time of this Writing 859 Marcelo Bagnulo 860 Gonzalo Camarillo 861 Stuart Cheshire 862 Vijay Gill 863 Russ Housley 864 John Klensin 865 Olaf Kolkman 866 Gregory Lebovitz 867 Andrew Malis 868 Danny McPherson 869 David Oran 870 Jon Peterson 871 Dave Thaler 873 Appendix A. Historical Background on Distributed Architectures 875 In this appendix, we briefly provide historical background on 876 distributed architectures. Distributed architectures are relevant to 877 P2P because P2P architectures are a type of distributed architecture. 878 That is, a distributed architecture is considered P2P if it meets a 879 set of requirements, which are discussed in Section 2. 881 In centralized architectures (e.g., client-server architectures), a 882 central server (or very few central servers) undertakes most of the 883 system's processing and storage. Conversely, decentralized 884 architectures contain no (or very few) centralized elements. 886 The increasing spread of packet-switched network technologies in the 887 1970s made it possible to develop operational distributed computer 888 systems [Farber1972]. Distributed computer systems received a lot of 889 attention within the research community. Research focused on 890 distributing the different parts of a computer system, such as its 891 operating system [Tanenbaum1981] or its databases [Gray1983]. The 892 idea was to hide from the user the fact that the system was 893 distributed. That is, the user did not have to worry or even be 894 aware of the fact that his or her files were stored in different 895 computers or the fact that his or her tasks were processed also in a 896 distributed way. Actions such as file transfers and task allocations 897 were taken care of by the system in an automated fashion and were 898 transparent to the user. 900 In the middle of the 1980s, building distributed computer systems 901 using general-purpose off-the-shelf hardware and software was 902 believed to be not much harder than building large centralized 903 applications [Gray1986A]. It was understood that distributed systems 904 had both advantages and disadvantages when compared to centralized 905 systems. Choosing which type of system to use for a particular 906 application was a tradeoff that depended on the characteristics and 907 requirements of the application [Gray1986B]. 909 The client-server paradigm, where a client makes a request to a 910 server that processes the request and returns the result to the 911 client, was and is used by many Internet applications. In fact, 912 client-server architectures were so ubiquitous on the Internet that, 913 unfortunately, the Internet itself evolved as if the majority of the 914 endpoints on the Internet were only interested in applications 915 following the client-server model. With the appearance of Network 916 Address Translators (NATs) and stateful firewalls, most Internet 917 endpoints lost the ability to receive connections from remote 918 endpoints unless they first initiated a connection towards those 919 nodes. While NATs were designed not to disrupt client-server 920 applications, distributed applications that relied on nodes receiving 921 connections were disrupted. In a network full of NATs, these types 922 of distributed applications could only be run among nodes with public 923 IP addresses. Of course, most users did not like applications that 924 only worked some of the time (i.e., when their endpoint happened to 925 have a public IP address). Therefore, the loss of global 926 connectivity caused by NATs was one of the reasons why applications 927 that did not follow the client-server paradigm (e.g., P2P 928 applications) took a relatively long time to be widely deployed on 929 the public Internet. 931 The design of NAT traversal mechanisms has made it possible to deploy 932 all types of distributed applications over a network without global 933 connectivity. While the first NAT traversal mechanisms used by P2P 934 applications were proprietary [RFC5128], nowadays there are standard 935 NAT traversal mechanisms such as Interactive Connectivity 936 Establishment (ICE) [I-D.ietf-mmusic-ice]. ICE makes it possible for 937 endpoints to establish connections among them in the presence of 938 NATs. The recovery of global connectivity among Internet endpoints 939 has made it possible to deploy many P2P applications on the public 940 Internet (unfortunately, the fact that global connectivity is not 941 supported natively at the network layer makes it necessary for 942 applications to deal with NATs, which can result in highly complex 943 systems). Some of these P2P applications have been very successful 944 and are currently used by a large number of users. 946 Another factor that made it possible to deploy distributed 947 applications was the continuous significant advances in terms of 948 processing power and storage capacity of personal computers and 949 networked devices. Eventually, most endpoints on the Internet had 950 capabilities that previously were exclusively within the reach of 951 high-end servers. The natural next step was to design distributed 952 applications that took advantage of all that distributed available 953 capacity. 955 11. Informative References 957 [Alima2005] 958 Alima, L., Ghodsi, A., and S. Haridi, "A Framework for 959 Structured Peer-to-peer Overlay Networks", Global 960 Computing, vol 3267, Lecture Notes in Computer Science: 961 Springer Berlin / Heidelberg, pp. 223-249 , 2005. 963 [BitTorrent] 964 Cohen, B., "The BitTorrent Protocol Specification Version 965 11031", February 2008. 967 [Cooke2005] 968 Cooke, E., Jahanian, F., and D. McPherson, "The Zombie 969 roundup: understanding, detecting, and disrupting 970 botnets", Proceedings of the Steps to Reducing Unwanted 971 Traffic on the Internet Workshop , 2005. 973 [Dean2004] 974 Dean, J. and S. Ghemawat, "MapReduce: Simplified Data 975 Processing on Large Clusters", Sixth Symposium on 976 Operating System Design and Implementation (OSDI '04) , 977 December 2004. 979 [Douceur2002] 980 Douceur, J., "The Sybil Attack", IPTPS 02 , March 2002. 982 [Farber1972] 983 Farber, D. and K. Larson, "The Structure of a Distributed 984 Computer System - The Communications System", Proceedings 985 Symposium on Computer-Communications Networks and 986 Teletraffic, Microwave Research Institute of Polytechnic 987 Institute of Brooklyn pp. 21--27 , 1972. 989 [Feldman2004] 990 Feldman, M., Lai, K., Stoica, I., and J. Chuang, "Robust 991 Incentive Techniques for Peer-to-peer Networks", 992 Proceedings of the 5th ACM Conference on Electronic 993 Commerce , 2004. 995 [Foster1999] 996 Foster, I., "Computational Grids", Chapter 2 of The Grid: 997 Blueprint for a New Computing Infrastructure , 1999. 999 [Foster2003] 1000 Foster, I. and A. Iamnitchi, "On Death, Taxes, and the 1001 Convergence of Peer-to-Peer and Grid Computing", 2nd 1002 International Workshop in Peer-to-Peer Systems 1003 (IPTPS'02) , 2003. 1005 [Gkantsidis2005] 1006 Gkantsidis, C. and P. Rodriguez, "Network Coding for Large 1007 Scale Content Distribution", IEEE INFOCOM 2005, vol. 4 , 1008 March 2005. 1010 [Gray1983] 1011 Gray, J. and S. Metz, "Solving the Problems of Distributed 1012 Databases", Data Communications, pp. 183-192 , 1983. 1014 [Gray1986A] 1015 Gray, J., "An Approach to Decentralized Computer Systems", 1016 IEEE Transactions on Software Engineering, V 12.6, pp. 1017 684-689 , 1986. 1019 [Gray1986B] 1020 Gray, J. and M. Anderton, "Distributed Systems: Four Case 1021 Studies", IEEE Transactions on Computers and Tandem 1022 Technical Report 85.5 , 1986. 1024 [Gong2001] 1025 Gong, L., "JXTA: A Network Programming Environment", IEEE 1026 Internet Computing, vol. 5, no. 3, pp. 88-95 , 2001. 1028 [Grizzard2007] 1029 Grizzard, J., Sharma, V., Nunnery, C., Kang, B., and D. 1030 Dragon, "Peer-to-peer botnets: overview and case study", 1031 Proceedings of Hot Topics in Understanding Botnets 1032 (HotBots'07) , 2007. 1034 [Gurun2006] 1035 Gurun, S., Nagpurkar, P., and B. Zhao, "Energy Consumption 1036 and Conservation in Mobile Peer-to-Peer Systems", First 1037 International Workshop on Decentralized Resource Sharing 1038 in Mobile Computing and Networking (MobiShare 2006) , 1039 2006. 1041 [Huang2007] 1042 Huang, Y., Rabinovich, M., and Z. Xiao, "Challenges of P2P 1043 Streaming Technologies for IPTV Services", IPTC Workshop 1044 International World Wide Web Conference, Edinburgh, 1045 Scotland, United Kingdom , May 2006. 1047 [I-D.ietf-mmusic-ice] 1048 Rosenberg, J., "Interactive Connectivity Establishment 1049 (ICE): A Protocol for Network Address Translator (NAT) 1050 Traversal for Offer/Answer Protocols", 1051 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1053 [Juang2002] 1054 Juang, P., Oki, H., Wang, Y., Martonosi, M., Peh, L., and 1055 D. Rubenstein, "Energy-efficient computing for wildlife 1056 tracking: design tradeoffs and early experiences with 1057 ZebraNet", Proceedings of Conference on Computer and 1058 Communications Security (CCS), ACM , 2002. 1060 [Kanich2008] 1061 Kanich, C., Levchenko, K., Enright, B., Voelker, G., 1062 Paxson, V., and S. Savage, "Spamalytics: An Empirical 1063 Analysis of Spam Marketing Conversion", Proceedings of 1064 Conference on Computer and Communications Security (CCS), 1065 ACM , October 2008. 1067 [Kelenyi2008] 1068 Kelenyi, I. and J. Nurminen, "Energy Aspects of Peer 1069 Cooperation - Measurements with a Mobile DHT System", in 1070 Proc. of Cognitive and Cooperative Wireless Networks 1071 Workshop in the IEEE International Conference on 1072 Communications 2008, Beijing, China, pp. 164-168. , 2008. 1074 [Leibniz2007] 1075 Leibniz, K., Hobfeld, T., Wakamiya, N., and M. Murata, 1076 "Peer-to-Peer vs. Client/Server: Reliability and 1077 Efficiency of a Content Distribution Service", Lecture 1078 Notes in Computer Science, LNCS 4516, pp. 1161-1172 , 1079 2007. 1081 [Lua2005] Keong Lua, E., Crowcroft, J., Pias, M., Sharma, R., and S. 1082 Lim, "A Survey and Comparison of Peer-to-peer Overlay 1083 Network Schemes", IEEE Communications Surveys & Tutorials, 1084 vol. 7, no. 2, Second Quarter 2005, pp. 72 - 93 , 2005. 1086 [Mahajan2003] 1087 Mahajan, R., Castro, M., and A. Rowstron, "Controlling the 1088 Cost of Reliability in Peer-to-Peer Overlays", Proceedings 1089 of the 2nd International Workshop on Peer-to-Peer Systems 1090 (IPTPS '03) , 2003. 1092 [Milojicic2002] 1093 Milojicic, D., Kalogeraki, V., Lukose, R., Nagaraja, K., 1094 Pruyne, J., Richard, B., Rollins, S., and Z. Xu, "Peer-to- 1095 Peer Computing", Technical Report, HP , March 2002. 1097 [Mondal2006] 1098 Mondal, A. and M. Kitsuregawa, "Privacy, Security and 1099 Trust in P2P environments: A Perspective", 17th 1100 International Conference on Database and Expert Systems 1101 Applicationsn 2006 (DEXA'06) , September 2006. 1103 [Octoshape] 1104 "http://www.octoshape.com". 1106 [Oechsner2006] 1107 Oechsner, S., Hobfeld, T., Tutschku, K., Andersen, F., and 1108 L. Caviglione, "Using Kademlia for the Configuration of 1109 B3G Radio Access Nodes", Proceedings of the Fourth Annual 1110 IEEE International Conference on Pervasive Computing and 1111 Communications Workshops (PERCOMW'06) , 2006. 1113 [Peltotalo2008] 1114 Peltotalo, J., Harju, J., Jantunen, A., Saukko, M., and L. 1115 Vaeaetaemoeinen, "Peer-to-Peer Streaming Technology 1116 Survey", Seventh International Conference on Networking, 1117 Cancun, Mexico, pp. 342-350 , April 2008. 1119 [Pourebrahimi2005] 1120 Pourebrahimi, B., Bertels, K., and S. Vassiliadis, "A 1121 Survey of Peer-to-Peer Networks", Proceedings of the 16th 1122 Annual Workshop on Circuits, Systems, and Signal 1123 Processing, ProRisc 2005 , November 2005. 1125 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1126 STD 9, RFC 959, October 1985. 1128 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1129 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1130 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1132 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1133 A., Peterson, J., Sparks, R., Handley, M., and E. 1134 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1135 June 2002. 1137 [RFC4981] Risson, J. and T. Moors, "Survey of Research towards 1138 Robust Peer-to-Peer Networks: Search Methods", RFC 4981, 1139 September 2007. 1141 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1142 Peer (P2P) Communication across Network Address 1143 Translators (NATs)", RFC 5128, March 2008. 1145 [Rhea2005] 1146 Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., 1147 Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open 1148 DHT: A Public DHT Service and Its Uses", ACM/SIGCOMM 1149 CCR'05, vol. 35, Issue 4 , October 2005. 1151 [Rodriguez2005] 1152 Rodriguez, P., Tan, S., and C. Gkantsidis, "On the 1153 Feasibility of Commercial Legal P2P Content Distribution", 1154 ACM/SIGCOMM CCR'06 , January 2006. 1156 [Roussopoulus2004] 1157 Roussopoulus, M., Baker, M., Rosenthal, D., Guili, T., 1158 Maniatis, P., and J. Mogul, "2 P2P or Not 2 P2P", Workshop 1159 on Peer-to-Peer Systems , February 2004. 1161 [Schollmeier2001] 1162 Schollmeier, R., "A Definition of Peer-to-Peer Networking 1163 for the Classification of Peer-to-Peer Architectures and 1164 Applications", In Proceedings of the First International 1165 Conference on Peer-to-Peer Computing P2P'01 , 2001. 1167 [Seti] "http://setiathome.berkeley.edu". 1169 [Singh2006] 1170 Singh, A., Ngan, T., Druschel, T., and D. Wallach, 1171 "Eclipse Attacks on Overlay Networks: Threats and 1172 Defences", INFOCOM 2006 , April 2006. 1174 [Skype] "http://www.skype.com". 1176 [SNC] "http://www.snc.sapmi.net". 1178 [Tanenbaum1981] 1179 Tanenbaum, A. and S. Mullender, "An Overview of the Amoeba 1180 Distributed Operating System", ACM SIGOPS Operating 1181 Systems Review , 1981. 1183 [WoW] "http://www.worldofwarcraft.com". 1185 [Zhang2006] 1186 Zhang, Y., Chen, C., and X. Wang, "Recent Advances in 1187 Research on P2P Networks", In Proceedings of the Seventh 1188 International Conference on Parallel and Distributed 1189 Computing, Applications, and Technologies PDCAT'06 , 2006. 1191 Author's Address 1193 Gonzalo Camarillo (editor) 1194 Ericsson 1195 Hirsalantie 11 1196 Jorvas 02420 1197 Finland 1199 Email: Gonzalo.Camarillo@ericsson.com