RFC 5694
Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability
Abstract ✨
okay so bestie, this doc is a survey of P2P (Peer-to-Peer) systems 🧚 It explains what P2P even means, sorts P2P systems into taxonomies, shows which kinds of apps you can build with P2P tech, and gives examples of P2P apps people are actually using on the Internet right now. It also talks through the architectural trade-offs and gives guidelines for deciding whether a P2P setup fits what your app needs. Main character energy 💅
Status of This Memo 📋
this memo is informational 💖 it's for the Internet community, and it does not specify an Internet standard of any kind. Distribution of this memo is unlimited ✨
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. please actually read those, bc they spell out your rights and restrictions for this document 🙈 and if you pull Code Components out of this doc, they have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the BSD License says 🔥
Table of Contents 🗂️
1. Introduction ....................................................3
2. Definition of a P2P System ......................................3
2.1. Applying the P2P Definition to the DNS .....................5
2.2. Applying the P2P Definition to SIP .........................5
2.3. Applying the P2P Definition to P2PSIP ......................6
2.4. Applying the P2P Definition to BitTorrent ..................7
3. Functions in a P2P System .......................................7
4. Taxonomies for P2P Systems ......................................8
5. P2P Applications ...............................................10
5.1. Content Distribution ......................................10
5.2. Distributed Computing .....................................12
5.3. Collaboration .............................................13
5.4. Platforms .................................................14
6. Architectural Trade-Offs and Guidance ..........................14
7. Security Considerations ........................................16
8. Acknowledgements ...............................................19
9. IAB Members at the Time of This Writing ........................19
10. Informative References ........................................19
Appendix A. Historical Background on Distributed Architectures ...251. Introduction 🌸
okay so P2P (Peer-to-peer) systems have been everywhere lately 😭 there are a ton of scientific publications digging into different parts of P2P systems, several science conferences focus on P2P networking explicitly, and there's an Internet Research Task Force (IRTF) Research Group (RG) on P2P systems (the Peer-to-Peer RG) 🧚 there are also a bunch of commercial and non-commercial apps that run on P2P principles on the Internet. some of these P2P apps are literally among the most widely used apps on the Internet right now 💖
but here's the tea ☕ despite all of that, engineers who design systems or write protocol specs don't have a shared understanding of what P2P systems are 🙈 and the part that's lowkey alarming is that a lot of people in the telecom and datacom industries think P2P is basically synonymous with illegal activity, like illegally trading content over the Internet or P2P botnets 💀 that's not it, bestie.
so the goal of this doc is to talk through the trade-offs when you're deciding whether a particular app can be best designed and built using a P2P paradigm or a different model (for example, a client-server paradigm) ✨ it also aims to give architectural guidelines to help you make those calls. basically, it gives engineers a high-level understanding of what defines a P2P system, what types of P2P systems exist, the characteristics you can expect from them, and what kinds of apps can be built with P2P tech 🎀 that understanding is essential for actually appreciating the trade-offs we just mentioned. and we really want to stress that P2P systems can power perfectly legitimate apps and business models 💅 the doc shows that with several examples throughout.
2. Definition of a P2P System 🔍
okay first things first: to talk about P2P systems, we need a working definition of one 🫶 this section gives us that. all the discussions in this doc apply to systems that comply with that definition. we also include a few examples of systems that comply only partially with the definition, so they can't strictly be called P2P systems 🙈 since those systems aren't fully P2P compliant, some of the discussion may apply to them and some may not. we included them anyway to show that P2P and centralized architectures are not completely disjoint alternatives. there are plenty of systems that sit somewhere between pure P2P and centralized, which is giving hybrid 🌈
P2P is a term that gets thrown around in a lot of contexts, sometimes with slightly different meanings 🦋 if you dig into the existing scientific literature, you'll find several alternative definitions, and they aren't all fully equivalent. and if you also include other stuff (like marketing material) in your search for a P2P definition, the variety gets even bigger 💀
the real issue is that there's no clear border between a P2P paradigm and other supposedly opposite paradigms, like client-server [Milojicic2002]. at the extremes, some architectures are clearly P2P and others are clearly client-server ✨ but there are also architectures that could count as either or both, depending on which definition of P2P you're using. so it's important to figure out what's common to all definitions of P2P, and what the non-common traits are that some authors include in their own definitions 🍓
we consider a system to be P2P if the elements that form the system share their resources in order to provide the service the system was designed to provide 💖 the elements in the system both provide services to other elements and request services from other elements. that's the core vibe 🫶
in principle, all the elements in the system should meet the previous criteria for the system to count as P2P. but in practice, a system can have a few exceptions (a few nodes that don't meet the criteria) and still be considered P2P 🙌 for example, a P2P system can still be considered P2P even if it has a centralized enrollment server. on the flip side, some systems split endpoints into peers and clients 👑 peers both request and provide services, while clients generally only request services. a system where most endpoints act as clients couldn't strictly be considered P2P 😭
ok, here's a lowkey interesting one: although most definitions don't say it outright, a lot of them implicitly assume that for a system to be P2P, its nodes need to be involved in transactions related to services that don't directly benefit the nodes 🧚
some authors add that the elements that form a P2P system, which are unsurprisingly called peers, should be able to communicate directly between themselves without passing through intermediaries [Schollmeier2001] ✨ other authors add that the system should be self organizing and have decentralized control [Roussopoulus2004] 🦋
quick note: the definitions above are given in the context of a single individual service 🎀 but a complex service can be made up of several individual services. some of those can be P2P services and some can be client-server services 💅 for example, a file sharing client might include a P2P client to do the actual file sharing, plus a web browser to access extra info on a centralized web server. and there are architectures where a client-server system can serve as a fallback for a service that's normally provided by a P2P system, or vice versa 🌸
providing a service typically involves processing or storing data 🍓 according to our definition, in a P2P system, peers share their processing and storage capacity (that is, their hardware and software resources) so the system can provide a service. for example, if the service is a file distribution service, different peers in the system will store different files. when a given peer wants a particular file, it first discovers which peer or peers have that file, and then gets the file from those peers 🫶
the definition for P2P gives us a criterion for deciding whether a system is P2P or not ✨ so in the following sections, we apply the definition to DNS, SIP, P2PSIP, and BitTorrent and discuss which of these systems are P2P 🔥
2.1. Applying the P2P Definition to the DNS 🌐
the DNS is a hierarchical distributed system that has sometimes been classified as a hierarchical client-server system, and sometimes as a P2P system [Milojicic2002] 🤔 according to our definition, the DNS is not a P2P system, because DNS resolvers are service requesters but not service providers 💀 the elements in a system need to be both service requesters and service providers for the system to be considered P2P. so yeah, DNS is giving client-server, not P2P 🙅♀️
(Part 1 of 8, more coming bestie 🧚💖)
2.2. Applying the P2P Definition to SIP ✨
okay so SIP [RFC3261] is a rendezvous protocol 💖 it lets one user find a remote user and set up a communication session with them. Once the remote user is located, sessions get set up the same way in every SIP system: directly between the nodes in the session 🫶 but the rendezvous part can be done in two different ways: the traditional SIP way and the P2P way. this section is about the traditional way, and Section 2.3 covers the P2P way 🎀
in traditional SIP, a central server is usually in charge of a DNS domain 🏠 user agents in that domain register with the server 💅 so when one user agent wants to talk to another user agent in the same domain, it asks the server, and the server hands back the remote user agent's contact info. then the session is set up directly between the user agents, and the server isn't involved anymore 🦋
inter-domain communication in SIP is done with server federations 👑 the servers for each domain form a federation where they can talk to each other. so when a user agent wants to reach a remote user agent in a different domain, it asks its local server, and that server asks the server responsible for the remote user agent's domain. it's giving teamwork 🧚
SIP user agents act as both clients and servers 🌈 a user agent can be a client in one transaction and a server in the next one. BUT traditional SIP cannot be called a P2P system, bestie 🙈 user agents only share their resources for their own benefit. a given user agent only gets involved in transactions for a service that benefits (somehow) that same user agent. for example, a user agent only shows up in SIP INVITE transactions meant to set up sessions that involve that user agent. for a system to be P2P, its nodes need to be in transactions that benefit others, meaning transactions for services that don't benefit the nodes directly. ngl that's the whole vibe check 💜
2.3. Applying the P2P Definition to P2PSIP 🦋
in addition to the traditional way of using SIP, SIP can also be used in a way that's generally called P2PSIP (P2PSIP is the name of the IETF working group developing the technology 📝). in P2PSIP, user agents don't register their contact info with a central server. instead, they register it with an overlay formed by the user agents in the system 🕸️ so when a user agent wants to talk to a remote user agent, it asks the overlay, and the overlay returns the remote user agent's contact info. then the session gets set up, as usual, directly between the user agents ✨
P2PSIP is a P2P system because nodes share their resources by storing data that isn't related to them (like the contact info of different user agents) 🎁 and they're involved in transactions for services that don't revert directly to the nodes themselves (for example, the rendezvous of two remote user agents). this is so iconic, no cap 😭🔥
2.4. Applying the P2P Definition to BitTorrent 🌸
BitTorrent [BitTorrent] is a protocol used to distribute files 🍓 the group of endpoints involved in distributing a particular file is called a swarm 🐝 the file is split into several pieces. an endpoint that's interested in the file needs to download all of the pieces from other endpoints in the swarm. endpoints that are downloading pieces also upload the pieces they already have to other endpoints in the swarm 🔄 an endpoint that both downloads (because it doesn't have the complete file yet) and uploads pieces is called a leecher. (ik, the name is kinda counterintuitive, because in other contexts a leecher normally means someone who takes but doesn't give 🙈) once an endpoint has the whole file (meaning it has all the pieces), it doesn't need to download any pieces anymore, so it only uploads them to other endpoints. that endpoint is called a seeder 🌱
BitTorrent systems are P2P systems because endpoints request services from other endpoints (they download pieces from them) and provide services to other endpoints (they upload pieces to them) 🤝 BUT, and this is a big but 💀, a swarm where most endpoints are infrastructure nodes that had the complete file from the start, and so acted as seeders the whole time, could not be strictly considered a P2P system. the reason is that most endpoints would only be providing services, never requesting them.
3. Functions in a P2P System 🧩
P2P systems include several functions 💅 the following functions don't depend on the service the P2P system provides. they handle how peers connect to the system.
- Enrollment function: nodes joining a P2P system need to get valid credentials to join the system 🔐 the enrollment function handles node authentication and authorization.
- Peer discovery function: to join a P2P system (meaning, to become a peer), a node needs to set up a connection with one or more peers that are already part of the system 👀 the peer discovery function lets nodes find peers in the system so they can connect to them.
the functions above are provided in a centralized way in some P2P systems (for example, through a central enrollment server and a central peer discovery server, which is sometimes called a bootstrap server 🥾). taxonomies for P2P systems, which we'll get to in Section 4, don't consider these functions when they classify P2P systems. instead, they classify P2P systems based on how the following set of functions is implemented 📊
the following functions do depend on the service the P2P system provides 🎯 so not every P2P system implements every function. for example, a P2P system used only for storing data might not implement the computation function. another example: a P2P system used only for computing might not implement the data storage function. also, some of these functions are implemented in a centralized way in some P2P systems.
- Data indexing function: it deals with indexing the data stored in the system 🗂️
- Data storage function: it deals with storing and retrieving data from the system 📦
- Computation function: it deals with the computing performed by the system ⚙️ that computing can be related to things like data processing or real-time media processing, among other things 🎬
- Message transport function: it deals with message exchanges between peers 💌 depending on how this function is implemented, peers can exchange protocol messages through a central server, directly between themselves, or through peers that provide overlay routing 🛣️
depending on the service being provided, some of the functions above might not be needed. Section 5 talks about different types of P2P applications, and each one implements different services 💖
4. Taxonomies for P2P Systems ✨
okay so taxonomies are basically how we sort things into groups so they're easier to study 🗂️ people who look at similar stuff can focus on the same problems, and they also give everyone the same vocab so we're not all talking past each other. so in this section we're gonna drop a few taxonomies for P2P systems to make them easier to study and to lock in some shared terminology 🫶
ngl it's not shocking that there are a bunch of different taxonomies, because different authors can't seem to agree on one single definition for P2P 💀 sorting systems by different traits is totally normal, but the same term can mean different things depending on who's talking (like, first and second generation P2P systems mean different things to different authors), and that can be super confusing for readers 😭
the most useful way to classify P2P systems is probably by how data is indexed 🔍 aka how the data indexing function is actually implemented. a P2P index can be centralized, local, or distributed [RFC4981]. with a centralized index, a central server keeps references to the data on all the peers. with a local index, each peer only keeps references to its own data. with a distributed index, references to data live on several nodes. Napster, early versions of Gnutella (up to version 0.4), and Distributed Hash Table (DHT)-based systems are the examples of centralized, local, and distributed indexes, respectively 🎀
indexes can also be sorted into semantic and semantic-free 🧠 a semantic index can capture relationships between documents and their metadata, whereas a semantic-free index cannot [RFC4981]. semantic indexes give you richer searches, BUT they sometimes (depending on how they're implemented) fail to find the data even when it's actually in the system 💀 so it's a trade-off, bestie
some authors sort P2P systems by how decentralized they are 🌐 hybrid P2P systems need a central entity to provide their services, while pure P2P systems can keep providing their services even if any single peer gets removed from the system [Schollmeier2001]. by this definition, P2P systems with a centralized index are hybrid, and systems with local or distributed indexes are pure 💅
then some authors sort pure P2P systems by how much structure they have [Alima2005]. in unstructured systems, peers join by connecting to any other existing peers 🌸 in structured systems, peers join by connecting to well-defined peers based on their logical identifiers 🧚 the line between early unstructured systems (like early versions of Gnutella), which used local indexes and had no structure at all, and structured systems (like the DHT-based ones), which used distributed indexes and had a well-defined structure, was pretty clear back then ✨ BUT unstructured systems have evolved and now show a certain level of structure (e.g., some systems have special nodes with more functionality) and use distributed indexes 😭 so yeah, the border between unstructured and structured is kinda blurry now, no cap
and then there's the generations thing 🙈 for some authors, the first, second, and third generations are P2P systems using centralized indexes, flooding-based searches (i.e., using local indexes), and DHTs (i.e., DHT-based distributed indexes), respectively [Foster2003]. other authors say second generation systems can also have non-DHT-based distributed indexes [Zhang2006]. and for yet other authors, the first and second generations are P2P systems using unstructured (typically using flooding-based searched) and structured (e.g., DHT-based) routing, respectively [RFC4981]. honestly, talking about generations isn't useful in a technical context (we already said it's more useful to classify systems by how they index data 💖), because the generations are defined in different ways depending on the author, AND because it gives the impression that later generations are automatically better than earlier ones 🙄 depending on the application, an earlier-generation P2P system might meet the app's requirements better than a later-generation one. it's giving "newer isn't always better" 💅
as we talked about in Section 3, the taxonomies above don't consider the enrollment and peer discovery functions 🔎 for example, a pure P2P system would still count as pure even if it had centralized enrollment and peer discovery servers. wild, right? 🤷♀️
5. P2P Applications 🌈
okay so P2P applications built so far can be sorted into these domains [Pourebrahimi2005] [Milojicic2002]: content distribution, distributed computing, collaboration, and platforms 🍓
5.1. Content Distribution 🎬
when most people hear P2P, they think file sharing 📀 and specifically illegal file sharing, where people swap material (songs, movies, and software in digital format) they aren't legally allowed to distribute. BUT despite what people think, P2P file sharing systems aren't inherently illegal 🙅♀️
P2P file sharing apps are just one of many ways to store and distribute content on the Internet 🌍 HTTP [RFC2616] and FTP [RFC0959] servers are other examples of content distribution mechanisms. nobody says HTTP is illegal just because some users upload stuff that can't legally be distributed to an HTTP server where other users download it 😤 same energy here: it's misleading to say P2P is illegal just because some users use it for illegal stuff 💅
P2P content distribution systems are used to build legit apps and business models that take advantage of what these systems are good at 💖 legit uses include distributing pre-recorded TV programs [Rodriguez2005], Linux distributions [Rodriguez2005], game updates [WoW], and live TV [Peltotalo2008] [Octoshape], as long as the parties doing the distributing are legally authorized to do it (e.g., the content owner) ✨
the biggest advantage of P2P content distribution is scalability 📈 in general, the more popular the content, the more scalable the P2P system is 🔥 the peer that has the original content (i.e., the owner of a file or the source of an audio or video stream) hands it to a fraction of the peers interested in it, and those peers pass it along to other peers who want it too 🫶 note that, in general, there's no requirement for peers distributing content to be able to access it themselves (e.g., the content may be encrypted so that peers without the decryption key are content distributors but not content consumers) 🔐 peers can distribute content in different ways: the whole content, pieces of the content (i.e., swarming), or linear combinations of pieces of content [Gkantsidis2005] 🧩 either way, the end result is that the peer with the original content doesn't have to send the whole thing to every interested peer, like it would with a centralized server. so the capacity of the system isn't limited by the processing power and bandwidth of the peer with the original content, and the quality of the whole service goes up 🚀
an important part of what shapes a P2P distribution system is its peer selection process 🎯 and honestly, the different parties involved all want different things. users want to connect to peers that have the content they want, plus high bandwidth, high processing capacity, and low latency so transfers are faster 🏃♀️ the Content Delivery Network (CDN) operator wants peers to connect first to the peers holding the rarest pieces of the content being distributed, to improve the reliability of the system (in case those peers with the rare pieces leave the system) 🛟 network operators want peers to do local transfers inside their own network, so their peering and transit agreements aren't negatively affected (i.e., by downloading content from a remote network even though it's available locally) 😬 sometimes all of these requirements can be met at once (e.g., a peer with a rare piece has high bandwidth and processing capacity and is on the local network) 🎉 BUT other times the system can only try to reach acceptable trade-offs when selecting peers 🤝 these issues were the subject of the IETF P2P Infrastructure (P2PI) workshop held in 2008 🗓️
network operators also find that, depending on how their networks are dimensioned (e.g., where the bottlenecks are), the different traffic patterns generated by P2P or centralized CDNs can be more or less easily accommodated by the network [Huang2007] 🚦
here's a fun one: ZebraNet is an example of a sensor network based on P2P content distribution and Delay-tolerant Networking (DTL) [Juang2002] 🦓 ZebraNet is a network used to track zebras in the wild. each zebra wears a tracking collar that gathers data about the zebra (e.g., its position) at different times 📍 mobile stations talk to the collars wirelessly to collect and consolidate data from different zebras. BUT not every zebra gets close enough to a mobile station for its collar to talk to the station, so the collars communicate with each other and swap the data they've gathered 🔄 this way, a given collar can pass the mobile station data from different zebras, some of which might never get close enough to the mobile station themselves 😭 P2P networks are especially useful where it's impossible to deploy a communication infrastructure (e.g., due to national park regulations or potential vandalism), like in the example above, or when tracking reindeer in Lapland [SNC] (this project has focused on DTNs more than on P2P so far, but some of its main constraints are similar to the ones in ZebraNet) 🦌 note however that sensor networks like ZebraNet can't strictly be considered P2P, because the only node issuing service requests (i.e., the only node interested in receiving data) is a central node (i.e., the mobile station) 📱 so it's not fully P2P, and that's okay 🫶
5.2. Distributed Computing 💻✨
Okay so in P2P distributed computing, each task gets chopped into independent subtasks that can all be finished in parallel (aka no talking between tasks, bestie 🫶). A peer grabs a subtask, does the work with its own resources, and sends the result back. Once every subtask is done, all the results get combined to make the answer to the original task. Iconic 💅
Peers in these systems are usually spread out geographically and connected over wide-area networks 🌍. Cluster computing is the opposite vibe. Nodes in a cluster are usually physically close (often in the same room 🙈) and have excellent communication with each other. So clusters can divide tasks into subtasks that are not completely independent from one another and that cannot be completed in parallel. The excellent communication among the cluster nodes makes it possible to synchronize the completion of those tasks. Since computers in a cluster are so tightly integrated, cluster computing techniques are not typically considered P2P networking 🤝
The main advantage of P2P distributed computing is that a bunch of regular computers can deliver the performance of a much more powerful (and typically pricey) computer 🤑 That's giving main character energy. Nevertheless, at present, P2P distributed computing can only be applied to tasks that can be divided into independent subtasks that can be completed in parallel. Tasks that don't have this characteristic are better performed by a single powerful computer 💪
Note that even though distributed computing, in general, can be considered P2P (which is why it's in this section as an example of a P2P application 🎀), most current systems whose main focus is distributed computing don't fully comply with the definition for P2P provided in Section 2. The reason is that in those systems, service requests are typically generated only by a central node. Most nodes don't generate service requests (i.e., create tasks), so this is why Grid computing [Foster1999] cannot be strictly considered P2P [Lua2005]. SETI@home (Search for Extra-Terrestrial Intelligence) [Seti] is another well-known example that can't strictly be considered P2P either. It uses the resources of many computers to analyze radio telescope data 👽 MapReduce [Dean2004], a programming model for processing large data sets, also can't strictly be P2P for the same reason. On the other hand, a number of collaboration applications implement distributed computing functions in a P2P way (see Section 5.3) ✨
Another form of distributed computing that can't be strictly considered P2P (despite its name) is P2P botnets [Grizzard2007] 🙃 In P2P botnets, service requests usually consist of generating spam or launching Distributed Denial-of-Service (DDoS) attacks, and they're typically generated by a central node (or a few central nodes). That's why they can't be strictly considered P2P. An example of this type of P2P botnet that propagates using a DHT-based overlay is the Storm botnet [Kanich2008]. On top of their distributed propagation techniques, some P2P botnets also use a distributed command and control channel, which makes them harder to combat than traditional botnets using centralized channels [Cooke2005] 😬 DHT-based overlays can also be used to support the configuration of different types of radio access networks [Oechsner2006] 📡
5.3. Collaboration 🫂
P2P collaboration applications include communication apps like Voice over IP (VoIP) and Instant Messaging (IM) apps. Section 2.3 covered P2PSIP systems, which are an example of a standard-based P2P collaboration application. There are also proprietary P2P collaboration applications on the Internet [Skype] 📞 Collaboration apps typically provide rendezvous, Network Address Translators (NAT) traversal, and a set of media-related functions (e.g., media mixing or media transcoding). Note that some of these functions (e.g., media transcoding) are, effectively, a form of distributed computing. Literally so 🧠
P2P rendezvous systems are especially useful when there's no infrastructure 🏕️ Examples include a few people with no Internet connectivity setting up an ad hoc system to exchange documents, or the members of a recovery team communicating among themselves in a disaster area. P2PSIP is sometimes called infrastructureless SIP, to tell it apart from traditional SIP, which relies on a rendezvous server infrastructure 🦋
5.4. Platforms 🧩
P2P platforms can be used to build applications on top of them. They provide functionality that the applications on top can use, kind of like a foundation 🏗️ An example of such a platform is JXTA [Gong2001]. JXTA provides peer discovery, grouping of peers, and communication between peers. The goal with these types of P2P platforms is for them to become the preferred environment for application developers, and they take advantage of the good scalability properties of P2P systems. Honestly iconic behavior 👑✨
6. Architectural Trade-Offs and Guidance ✨
Okay so, bestie, we've covered a lot of P2P ground at this point 🦋 and I need to kill a myth once and for all: P2P is NOT only for shady stuff 🙅♀️. We've already looked at a bunch of totally legit apps that run on P2P, like video calls [Skype], distributing pre-recorded TV shows [Rodriguez2005], Linux distros [Rodriguez2005], game updates [WoW], and live TV [Peltotalo2008] [Octoshape]. The catch is that the parties distributing that content have to be legally allowed to do it 💅.
Now, when you're deciding whether a P2P architecture is the move for an app, you have to look at what P2P systems are generally like and then check that against what the app actually needs 🤔. There's no magic rule that tells you "yes P2P" or "no P2P," sorry 🙈. Instead, I'm going to walk through a set of trade-offs you should weigh when making architecture calls, plus some guidance on which kinds of requirements P2P handles best (we'll get into the security side in Section 7 🔐). At the end of the day, every app's operational requirements need to be analyzed case by case so you can pick the most suitable architecture. Iykyk 💜.
P2P is a solid pick when there's no existing infrastructure and building it is hard for some reason 🧚. Ad hoc systems are usually great candidates for P2P architectures ✨. Disaster areas where the existing infrastructure has been wrecked or made unusable can benefit from P2P systems too, which is honestly such a good use case 🌸.
Scalability is one of P2P's biggest moments 👑. Since the system can tap into the processing and storage capacity of all the peers, when the load goes up, the peers just use more of their processing or storage. And adding new peers usually adds load, but it also adds processing and storage capacity, so the system grows with the crowd. Basically, there's no typical need to update any central servers to handle more users or more load [Leibniz2007] 🙌. Adaptive P2P systems can even tune themselves to run in the best possible mode when things like the number of peers or the churn rate change [Mahajan2003] 🎀. Real talk though, keeping a running DHT takes nontrivial operational effort at present [Rhea2005] 😮💨.
Robustness and reliability matter a ton in lots of systems 🫶. For many apps to be useful, they have to be dependable [RFC4981]. Centralized servers can be made highly available with plenty of techniques, but peers in a P2P system aren't generally expected to be highly available (though, of course, you could build a more expensive P2P system using only highly available peers 💸). P2P systems are designed to survive peers leaving ungracefully, like crashing 💥. To keep things reliable, they use stuff like data replication and redundant routing table entries 🛟. So if a peer crashes, the data it stored isn't lost and can still be found in the system. Main character energy for sure 🌈.
How a P2P system performs compared to a server-based one depends on a lot of factors, like how the server-based system was dimensioned in the first place 📏. One of the biggest factors is the type of task being done. As we talked about in Section 5.2, if the job can be split into independent subtasks that run in parallel, a P2P distributed computing system made up of regular computers might outperform even a supercomputer 🤯. But if the task is mostly completing database queries, a well-dimensioned centralized database may be faster than a DHT 🗃️.
P2P performance can take a hit when the peers don't cooperate with each other 😤. That's why it's important to have incentives in place to minimize the number of free riders in the system 🚫. Incentive systems generally aim to bring the P2P system up to optimal levels of cooperation [Feldman2004] 🤝.
There are also trade-offs between the scalability, robustness, and performance of a particular P2P system, and you can tune those by how you configure the system 🎛️. For example, imagine a P2P database where every peer stored all the information in the system. That would be robust and fast (queries would finish quickly), but it wouldn't be efficient or scalable at all 🙃. If the system needed to grow, you could configure it so each node only stores part of the information. That boosts efficiency and scalability, but it costs you some robustness and performance 🍓.
Energy consumption is another big deal 🔋. Even though a client-server system overall usually uses less energy than a P2P system providing the same service, P2P systems avoid central servers (like server farms) that can concentrate a huge amount of energy use in one geographical location 🌍. When the nodes in a system need to be up and running all the time anyway, you can use those nodes to do tasks in a P2P way ⚡. Battery-powered devices as peers are trickier, though 🪫. A peer typically burns more energy than a client in a client-server architecture, where clients can go to sleep mode more often [Kelenyi2008] 😭. Energy-aware P2P protocols might be the answer to these challenges [Gurun2006] 💚.
This section has covered some important system properties and compared P2P with centralized systems on each one 📋. But honestly, the factor that matters most is often cost 💰. Both capital and operating costs have to be considered when you evaluate a system's scalability, reliability, and performance 🧾. If updating a server so it can handle more load is cheap, a server-based architecture might be the best option 🖥️. If a highly available server is expensive, a P2P system might be the best choice instead 🤑. And on the operating cost side, like we said before, keeping a running DHT takes nontrivial operational effort at present [Rhea2005] 🙄.
Quick lowkey reminder: understanding the general properties of P2P and server-based systems is super important, but picking the right architecture for an app means digging into detailed info about that specific app and its context 🔍. In most scenarios, there are no easy rules that tell you when to use which architecture 💖.
7. Security Considerations 🔐
okay bestie, security is the part where we get serious for a sec 🫶 Choosing an architecture means thinking about who you can actually trust in the system. The first big question is how much you trust the nodes. If every node is fully trusted (like, they're all under the full control of the operator and will never act maliciously or even by accident wrong 💅), a P2P architecture can reach a really high level of security. But if nodes aren't fully trusted and might act maliciously (say, launching active attacks) 😭, keeping things secure in a P2P environment gets way harder than in a non-P2P one. That's because ownership is spread out, there's no central control, and nobody has the global view of the whole thing [Mondal2006]. Ultimately, the security of a P2P system mostly depends on what fraction of its nodes behave maliciously. With a huge number of malicious nodes, keeping things secure can easily become impossible 💀
P2P systems can be abused by attackers to harvest IP addresses that are in use 👀 Attackers can passively collect valid IP addresses of potential victims without scanning anything, because a given peer is usually connected to multiple other peers. Being passive is only part of the appeal, though. This is also way more efficient than scanning when the address space is large and sparsely populated, like the current IPv6 address space 🌌 And there's often a strong correlation between a particular application and a particular operating system. So an attacker can harvest addresses that are good targets for attacks exploiting vulnerabilities specific to a given operating system. Iconic villain behavior, honestly 🙈
Central elements in centralized architectures are obvious targets for attacks 🎯 P2P systems minimize the number of central elements, so they're more resilient against attacks aimed at just a few elements. Slay 💖
When you're designing a P2P system, you need to think about a bunch of threats that are specific to P2P systems ✨ Also, more general threats that apply to every architecture are sometimes bigger in a P2P environment, so don't sleep on those. P2P-specific threats mainly focus on the data storage functions and the routing of P2P systems 🧚
In a P2P system, messages (like service requests) between two peers generally pass through a set of intermediate peers that help route them 📨 Those intermediate peers can try on-path attacks that they couldn't launch if they weren't on the path between the two peers 😬 An attacker can also try to pick a logical location in the P2P overlay that lets it launch on-path attacks against a particular victim or a set of victims. The Sybil attack [Douceur2002] is an example of this. The attacker chooses its overlay identifier so that it can launch future attacks. This kind of attack can be mitigated by controlling how peers obtain their identifiers, for example by having a central authority 🔑
A trivial passive attack by peers that route messages is simply trying to read the contents of those messages 👀 Encrypting the parts of a message that aren't needed for routing is an obvious defense against this 🔒
An attacker can create a message and claim that another peer created it 🙅♀️ The attacker can even take a legitimate message as a starting point and modify it to launch the attack. Peer and message authentication techniques can be used to prevent this type of attack 🫶
Attackers can also try a set of attacks against the storage function of the P2P system. The following are generic attacks, meaning they're not specific to P2P. Even though they're generic, avoiding or mitigating them in a P2P system can be trickier than in other architectures 😤
An attacker can try to store too much data in the system 📦 A quota system that can be enforced can be used to mitigate this.
Unauthorized peers can try to perform operations on data objects 🚫 Peer authorization combined with peer authentication avoids unauthorized operations.
A peer can return forged data objects while claiming they're legitimate 🫠 Data object authentication prevents this attack. However, a peer can also return a previous version of a data object and claim it's the current version. Using lifetimes can mitigate this type of attack ⏳
The following are P2P-specific attacks against the data storage function of a P2P system 😱 An attacker can refuse to store a particular data object. An attacker can also claim that a particular data object doesn't exist, even if another peer created it and stored it on the attacker. These DoS (Denial-of-Service) attacks can be mitigated by using data replication techniques and by performing multiple, typically parallel, searches 🔁
Attackers can also try a set of attacks against the routing of the P2P system 🗺️ An attacker can try to modify the routing of the system so it can launch on-path attacks. For this, attackers can use forged routing maintenance messages. The Eclipse attack [Singh2006] is an example of such an attack 🌑
Enforcing structural constraints or enforcing node degree bounds can mitigate this type of attack 💅
It's possible to launch DoS attacks by modifying or dropping routing maintenance messages, or by creating forged ones 📉 Having nodes get routing tables from multiple peers can help mitigate this type of attack.
Attackers can also launch a DoS attack by creating churn 🌪️ By leaving and joining a P2P overlay rapidly, many times over, a set of attackers can generate large amounts of maintenance traffic and make the overlay's routing structure unstable. Limiting the amount of churn per node is a possible defense against this attack.
8. Acknowledgements 🫶
Jouni Maenpaa and Jani Hautakorpi helped with the literature review 📚 Henning Schulzrinne shared useful ideas on how to define P2P systems 💡 Bruce Lowekamp, Dan Wing, Dan York, Enrico Marocco, Cullen Jennings, and Frank Uwe Andersen gave useful comments on this document 💌 Loa Andersson, Aaron Falk, Barry Leiba, Kurtis Lindqvist, Dow Street, and Lixia Zhang took part in the IAB discussions on this document 🎀
9. IAB Members at the Time of This Writing 👑
Here's the IAB squad at the time this was written 🌸
- Marcelo Bagnulo
- Gonzalo Camarillo
- Stuart Cheshire
- Vijay Gill
- Russ Housley
- John Klensin
- Olaf Kolkman
- Gregory Lebovitz
- Andrew Malis
- Danny McPherson
- David Oran
- Jon Peterson
- Dave Thaler
10. Informative References ✨
okay bestie, this is the reading list 📚 every single source the doc leans on, kept exactly as written so nothing gets lost 🫶
[Alima2005] Alima, L., Ghodsi, A., and S. Haridi, "A
Framework for Structured Peer-to-peer Overlay
Networks", Global Computing, vol. 3267, Lecture
Notes in Computer Science: Springer Berlin /
Heidelberg, pp. 223-249, 2005.
[BitTorrent] Cohen, B., "The BitTorrent Protocol Specification
Version 11031", February 2008.
[Cooke2005] Cooke, E., Jahanian, F., and D. McPherson, "The
Zombie roundup: understanding, detecting, and
disrupting botnets", Proceedings of the Steps to
Reducing Unwanted Traffic on the Internet
Workshop, 2005.
[Dean2004] Dean, J. and S. Ghemawat, "MapReduce: Simplified
Data Processing on Large Clusters", Sixth
Symposium on Operating System Design and
Implementation (OSDI '04), December 2004.
[Douceur2002] Douceur, J., "The Sybil Attack", IPTPS 02,
March 2002.
[Farber1972] Farber, D. and K. Larson, "The Structure of a
Distributed Computer System - The Communications
System", Proceedings Symposium on Computer-
Communications Networks and Teletraffic,
Microwave Research Institute of Polytechnic
Institute of Brooklyn pp. 21-27, 1972.
[Feldman2004] Feldman, M., Lai, K., Stoica, I., and J. Chuang,
"Robust Incentive Techniques for Peer-to-peer
Networks", Proceedings of the 5th ACM Conference
on Electronic Commerce, 2004.
[Foster1999] Foster, I., "Computational Grids", Chapter 2 of
The Grid: Blueprint for a New
Computing Infrastructure, 1999.
[Foster2003] Foster, I. and A. Iamnitchi, "On Death, Taxes,
and the Convergence of Peer-to-Peer and Grid
Computing", 2nd International Workshop in Peer-
to-Peer Systems IPTPS '02, 2003.
[Gkantsidis2005] Gkantsidis, C. and P. Rodriguez, "Network Coding
for Large Scale Content Distribution", IEEE
INFOCOM 2005, vol. 4, March 2005.
[Gong2001] Gong, L., "JXTA: A Network Programming
Environment", IEEE Internet Computing, vol. 5,
no. 3, pp. 88-95, 2001.
[Gray1983] Gray, J. and S. Metz, "Solving the Problems of
Distributed Databases", Data Communications, pp.
183-192, 1983.
[Gray1986A] Gray, J., "An Approach to Decentralized Computer
Systems", IEEE Transactions on Software
Engineering, V 12.6, pp. 684-689, 1986.
[Gray1986B] Gray, J. and M. Anderton, "Distributed Systems:
Four Case Studies", IEEE Transactions on
Computers and Tandem Technical Report 85.5, 1986.
[Grizzard2007] Grizzard, J., Sharma, V., Nunnery, C., Kang, B.,
and D. Dragon, "Peer-to-peer botnets: overview
and case study", Proceedings of Hot Topics in
Understanding Botnets (HotBots '07), 2007.
[Gurun2006] Gurun, S., Nagpurkar, P., and B. Zhao, "Energy
Consumption and Conservation in Mobile Peer-to-
Peer Systems", First International Workshop on
Decentralized Resource Sharing in Mobile
Computing and Networking (MobiShare 2006), 2006.
[Huang2007] Huang, Y., Rabinovich, M., and Z. Xiao,
"Challenges of P2P Streaming Technologies for
IPTV Services", IPTC Workshop International World
Wide Web Conference, Edinburgh, Scotland, United
Kingdom, May 2006.
[Juang2002] Juang, P., Oki, H., Wang, Y., Martonosi, M., Peh,
L., and D. Rubenstein, "Energy-efficient
computing for wildlife tracking: design tradeoffs
and early experiences with ZebraNet", Proceedings
of Conference on Computer and Communications
Security (CCS), ACM, 2002.
[Kanich2008] Kanich, C., Levchenko, K., Enright, B., Voelker,
G., Paxson, V., and S. Savage, "Spamalytics: An
Empirical Analysis of Spam Marketing Conversion",
Proceedings of Conference on Computer and
Communications Security (CCS) (ACM),
October 2008.
[Kelenyi2008] Kelenyi, I. and J. Nurminen, "Energy Aspects of
Peer Cooperation - Measurements with a Mobile DHT
System", in Proc. of Cognitive and Cooperative
Wireless Networks Workshop in the IEEE
International Conference on Communications 2008,
Beijing, China, pp. 164-168, 2008.
[Leibniz2007] Leibniz, K., Hobfeld, T., Wakamiya, N., and M.
Murata, "Peer-to-Peer vs. Client/Server:
Reliability and Efficiency of a Content
Distribution Service", Lecture Notes in Computer
Science, LNCS 4516, pp. 1161-1172, 2007.
[Lua2005] Keong Lua, E., Crowcroft, J., Pias, M., Sharma,
R., and S. Lim, "A Survey and Comparison of Peer-
to-peer Overlay Network Schemes", IEEE
Communications Surveys & Tutorials, vol. 7, no.
2, Second Quarter 2005, pp. 72-93, 2005.
[MMUSIC-ICE] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/
Answer Protocols", Work in Progress,
October 2007.
[Mahajan2003] Mahajan, R., Castro, M., and A. Rowstron,
"Controlling the Cost of Reliability in Peer-to-
Peer Overlays", Proceedings of the 2nd
International Workshop on Peer-to-Peer
Systems (IPTPS '03), 2003.
[Milojicic2002] Milojicic, D., Kalogeraki, V., Lukose, R.,
Nagaraja, K., Pruyne, J., Richard, B., Rollins,
S., and Z. Xu, "Peer-to-Peer Computing",
Technical Report HP, March 2002.
[Mondal2006] Mondal, A. and M. Kitsuregawa, "Privacy, Security
and Trust in P2P environments: A Perspective",
17th International Conference on Database and
Expert Systems Applications 2006 (DEXA '06),
September 2006.
[Octoshape] "Octoshape - Large Scale Live Streaming
Solutions", <http://www.octoshape.com>.
[Oechsner2006] Oechsner, S., Hobfeld, T., Tutschku, K.,
Andersen, F., and L. Caviglione, "Using Kademlia
for the Configuration of B3G Radio Access Nodes",
Proceedings of the Fourth Annual IEEE
International Conference on Pervasive Computing
and Communications Workshops (PERCOMW '06), 2006.
[Peltotalo2008] Peltotalo, J., Harju, J., Jantunen, A., Saukko,
M., and L. Vaatamoinen, "Peer-to-Peer Streaming
Technology Survey", Seventh International
Conference on Networking, Cancun, Mexico, pp.
342-350, April 2008.
[Pourebrahimi2005] Pourebrahimi, B., Bertels, K., and S.
Vassiliadis, "A Survey of Peer-to-Peer Networks",
Proceedings of the 16th Annual Workshop on
Circuits, Systems, and Signal Processing, ProRisc
2005, November 2005.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer
Protocol", STD 9, RFC 959, October 1985.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley,
M., and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[RFC4981] Risson, J. and T. Moors, "Survey of Research
towards Robust Peer-to-Peer Networks: Search
Methods", RFC 4981, September 2007.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of
Peer-to-Peer (P2P) Communication across Network
Address Translators (NATs)", RFC 5128,
March 2008.
[Rhea2005] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J.,
Ratnasamy, S., Shenker, S., Stoica, I., and H.
Yu, "Open DHT: A Public DHT Service and Its
Uses", ACM/SIGCOMM CCR'05, vol. 35, Issue 4,
October 2005.
[Rodriguez2005] Rodriguez, P., Tan, S., and C. Gkantsidis, "On
the Feasibility of Commercial Legal P2P Content
Distribution", ACM/SIGCOMM CCR'06, January 2006.
[Roussopoulus2004] Roussopoulus, M., Baker, M., Rosenthal, D.,
Guili, T., Maniatis, P., and J. Mogul, "2 P2P or
Not 2 P2P", Workshop on Peer-to-Peer Systems,
February 2004.
[SNC] "http://www.snc.sapmi.net".
[Schollmeier2001] Schollmeier, R., "A Definition of Peer-to-Peer
Networking for the Classification of Peer-to-Peer
Architectures and Applications", In Proceedings
of the First International Conference on Peer-to-
Peer Computing P2P '01, 2001.
[Seti] "SETI@home", <http://setiathome.berkeley.edu>.
[Singh2006] Singh, A., Ngan, T., Druschel, T., and D.
Wallach, "Eclipse Attacks on Overlay Networks:
Threats and Defences", INFOCOM 2006, April 2006.
[Skype] "Skype", <http://www.skype.com>.
[Tanenbaum1981] Tanenbaum, A. and S. Mullender, "An Overview of
the Amoeba Distributed Operating System", ACM
SIGOPS Operating Systems Review, 1981.
[WoW] "World of Warcraft Community Site",
<http://www.worldofwarcraft.com>.
[Zhang2006] Zhang, Y., Chen, C., and X. Wang, "Recent
Advances in Research on P2P Networks", In
Proceedings of the Seventh International
Conference on Parallel and Distributed Computing,
Applications, and Technologies PDCAT '06, 2006.Appendix A. Historical Background on Distributed Architectures ✨
okay so this appendix is the origin story 🎀 we're giving a quick history of distributed architectures, bc they matter for P2P. P2P architectures are a type of distributed architecture, so the whole family tree matters. a distributed architecture counts as P2P if it meets a set of requirements, and those requirements are covered in Section 2. 💅
In centralized architectures (e.g., client-server architectures), one central server (or a very small number of them) does most of the processing and storage. decentralized architectures are the opposite, with no centralized elements (or very few) 🦋
The spread of packet-switched network technologies in the 1970s made it possible to build operational distributed computer systems [Farber1972]. the research community was obsessed 😭 Researchers worked on splitting up the parts of a computer system, like its operating system [Tanenbaum1981] or its databases [Gray1983]. the goal was to hide from the user the fact that the system was distributed. so the user didn't have to worry about, or even know, that their files lived on different computers or that their tasks were processed in a distributed way. file transfers and task allocations were handled automatically by the system and were transparent to the user. that's the main character energy of good system design, fr fr ✨
In the middle of the 1980s, people believed that building distributed computer systems with general-purpose, off-the-shelf hardware and software wasn't much harder than building large centralized applications [Gray1986A]. it was understood that distributed systems had both advantages and disadvantages compared to centralized systems. picking which type to use for a given application was a trade-off, depending on that application's characteristics and requirements [Gray1986B]. no one-size-fits-all, bestie 🌸
The client-server paradigm is where a client sends a request to a server, the server processes it, and the result goes back to the client. it was, and still is, used by lots of Internet applications 🧚 client-server was SO ubiquitous that the Internet itself kind of evolved as if most endpoints only cared about client-server apps 🙈 then Network Address Translators (NATs) and stateful firewalls showed up, and most Internet endpoints lost the ability to receive connections from remote endpoints unless they had started the connection toward those nodes first 💀 NATs were designed not to break client-server applications, but distributed applications that relied on nodes receiving connections got wrecked. in a network full of NATs, those distributed applications could only run between nodes with public IP addresses. and honestly, users did not like apps that only worked some of the time (i.e., when their endpoint happened to have a public IP address) 😤 So the loss of global connectivity caused by NATs was one of the reasons that applications not following the client-server paradigm (e.g., P2P applications) took a relatively long time to be widely deployed on the public Internet. it's giving delayed glow-up 🫶
The design of NAT traversal mechanisms is what finally made it possible to deploy all types of distributed applications over a network without global connectivity. the first NAT traversal mechanisms used by P2P applications were proprietary [RFC5128]. nowadays, though, there are standard NAT traversal mechanisms, such as Interactive Connectivity Establishment (ICE) [MMUSIC-ICE]. ICE lets endpoints set up connections among themselves even when NATs are in the way 🦋 global connectivity coming back is what made it possible to deploy many P2P applications on the public Internet. (ngl, it's a little messy: global connectivity isn't supported natively at the network layer, so applications have to deal with NATs themselves, and that can make systems highly complex 😵💫) Some of these P2P applications have been super successful and are used by a large number of users right now. iconic 👑
Another factor that made distributed applications possible was the steady, significant progress in the processing power and storage capacity of personal computers and networked devices 🌈 eventually, most endpoints on the Internet had capabilities that used to be exclusively available to high-end servers. so the natural next step was designing distributed applications that could use all that distributed capacity. periodt 💖
Authors' Addresses
Gonzalo Camarillo (editor)
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Internet Architecture Board
EMail: iab@iab.org📦 where this page comes from
- ietf: rfc5694 2009-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms