idnits 2.17.1 draft-arkko-p2pi-incentives-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2008) is 5748 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-briscoe-tsvwg-relax-fairness-00 == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-04 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational July 29, 2008 5 Expires: January 30, 2009 7 Incentives and Deployment Considerations for P2PI Solutions 8 draft-arkko-p2pi-incentives-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 30, 2009. 35 Abstract 37 Several papers in the May 2008 P2PI workshop have argued that there 38 is a need to build new protocol mechanisms to accommodate peer-to- 39 peer traffic in networks in the most efficient way and with minimal 40 impact to other traffic. This paper presents an analysis of such 41 solutions from the point of view of the incentives of the different 42 parties involved in peer-to-peer traffic. The paper concludes that 43 it is essential to understand the incentives in order to have a 44 deployable solution. 46 1. Introduction 48 Peer-to-peer (P2P) networking has been cited as the leading consumer 49 of network bandwidth in networks serving private subscribers. This 50 is by itself not a problem, as the network providers are in the 51 business of providing a service to their customers, including the 52 ones that employ P2P tools. However, the issue is whether P2P 53 traffic causes undue congestion and reduced level of service for 54 other customers in the network [I-D.briscoe-tsvwg-relax-fairness]. 56 Historically, the Internet service provider market has developed for 57 interactive services where the bandwidth requirements for each user 58 vary significantly from over time. This allowed the service 59 providers to employ statistical multiplexing. At the same time, the 60 nominal link speeds have been a major factor in marketing Internet 61 service. But during the last few years, the nature of the traffic 62 has changed from interactive to more always-on type traffic, for 63 instance from P2P applications. As a result, statistical 64 multiplexing is no longer effective, and service providers are 65 finding that a large sets of users are actually trying to utilize 66 their full link speed at all times. This is making the service 67 providers either increase the capacity of their networks to match the 68 changing traffic mix and increasingly high broadband service speeds, 69 or find other ways to deal with the problems. 71 It is important to see that these problems are not limited to P2P 72 tools [P2PI.daigle]. Indeed, not even all P2P applications have 73 these problems. Some forms of video communication exhibit the same 74 problems that large file sharing P2P applications do [P2PI.hardie]. 75 And as the Internet applications evolve, we expect to see new forms 76 of traffic with these issues. In the remainder of this paper, we 77 assume any bandwidth-intensive, semi-permanently running application 78 that may or may not attempt to be friendly with other network usage. 80 The fairness problem can present itself in various ways. For 81 instance, users opening multiple transport sessions may get a 82 disproportionate share of a congested link. Permanent, high 83 bandwidth sessions may slow down the ramp-up of short-term, 84 interactive sessions. Or some users may utilize a transit link far 85 more than others, resulting in these users gaining a larger share of 86 the transit costs that the provider has to pay. 88 These problems are not just abstract issues. There has been highly 89 publicized debates about what forms of traffic management are 90 acceptable for network providers. In reality, network providers 91 already employ a number of techniques [P2PI.tschofenig]. Solutions 92 addressing issues in this space have been worked on by network 93 providers, vendors, and researchers. This paper looks at the 94 different classes of solutions in Section 2 and analyzes them based 95 on the incentives of the involved parties in Section 3. The key 96 issue is finding a solution that provides immediate benefits to 97 everyone who needs to add new mechanisms or equipment. Another key 98 issue is the information available to different parties. This leads 99 us to make conclusions in Section 4. 101 2. Solution Classes 103 A number of solutions have already been deployed to mitigate issues 104 caused by the changed traffic pattern. Other solutions are actively 105 being worked on. We divide the solutions in three rough classes, 106 based partially on similar classifications in [P2PI.tschofenig] 107 [P2PI.moncaster]: 109 Contractual 111 These solutions are based on choosing pricing models and 112 contractual conditions that persuade users to avoid always-on 113 traffic. For instance, volume-based accounting can be employed, 114 or the contracts of the heaviest users can be discontinued. 116 Voluntary changes in applications 118 These solutions are based on some change of behaviour in the 119 applications, leading to taking other users better into account, 120 reducing congestion or the use of expensive links, and so on. 122 Some of the solutions in this category include: 124 * Indicating the desired quality of service, so that interactive 125 and always-on applications can be distinguished in the network 126 [P2PI.moncaster]. This assumes that there is a basic level of 127 quality of service filtering capabilities in the network. 129 * Making decisions with better information about the network 130 topology and cost. For instance, algorithms that P2P 131 applications use to determine which peers to talk to can 132 probably be improved. One particular class of improvements 133 involves "oracles" in the service provider network to help 134 applications determine the most likely peers with good 135 connectivity. For instance, peers that are in the local 136 service provider network vs. behind an expensive and/or 137 congested transit service provider. 139 * New congestion control mechanisms. For instance, BitTorrent 140 has gotten positive results from their new algorithm 142 [P2PI.shalunov]. Another example is Bob Briscoe's re-ECN 143 mechanism [I-D.briscoe-tsvwg-re-ecn-tcp], which allows hosts 144 and networks to co-operate in the treatment of congestion, and 145 allows networks to treat different users in a fair manner. 147 Network-based mechanisms 149 These mechanisms are implemented solely in the network. Examples 150 include: 152 * Prioritization, slowdown, or even blocking of traffic based on 153 packet header information. Relatively complicated designs that 154 peek further into the packet, Deep Packet Inspection (DPI) have 155 also been deployed. Priorities can also be set based on user 156 accounting information, e.g., traffic shaping heavy users 157 during a rush hour. 159 * Changing the "scheduling algorithm", by attempting to complete 160 the short jobs first everyone's performance will improve. 161 Similar techniques as discussed above are needed to determine 162 which jobs are "short" and "long", however. 164 * Building caches and peer-to-peer network components in the 165 service provider network. 167 3. Incentives 169 This section discusses motives, deployment considerations, and how 170 information available to the different parties affects the 171 incentives. 173 3.1. Motives 175 For any solution to be adopted the involved parties have to have 176 compatible motives. This is not always trivial, because the parties 177 may either optimize for different goals, or because there is room for 178 malicious behaviour. 180 For instance, one type of a quality-of-service solution involves 181 voluntary marking of packets by applications and subsequent 182 differentiated treatment of these packets by the network. In this 183 case the motives of well-behaving users and service providers are 184 similar: both want interactive applications to be given more 185 priority, while allowing always-on batch applications to run in the 186 background, and take as much bandwidth as is available. However, if 187 the prioritization happens across multiple users, this also implies 188 that a lower priority marking has the potential to reduce the user's 189 share of the overall throughput. Clever users can distort the system 190 by claiming to run only interactive applications. A tragedy of the 191 commons follows: The optimal strategy from the point of view of the 192 entire group of users would be to correctly classify traffic. But 193 from the point of an individual user a better strategy would be to 194 lie. 196 Note that no misbehaviour is needed from a human user for this to 197 happen. It is enough that the user runs applications that do this. 198 And if such applications appear to produce better results than other 199 applications, the user has an incentive to use them. Having said 200 this, past experience tells us that a vast majority of networking 201 software plays by the rules. Attempts to improve or bypass TCP 202 congestion control are relatively rare, for instance. 204 An example where the motives themselves may be conflict is the co- 205 operation between P2P applications and service providers to determine 206 the "best" peers to connect to. The definition of "best" from the 207 P2P client perspective is a peer that has the highest possible actual 208 transfer rate. But the service provider is more interested in 209 minimization of their costs and overall network congestion. This may 210 or may not coincide with the client's desires. For instance, a 211 service provider may prefer a local peer with a slow access link over 212 a remote peer that is connected via an expensive transit connection. 214 While not part of the incentives, the available information to the 215 different parties plays an interesting role as well. It can be 216 expected that P2P nodes are capable of measuring actual transfer 217 rates across the end-to-end path, including the behaviour of the end 218 systems. P2P applications might even be able to accumulate this 219 information from multiple clients and over time. In contrast, the 220 service provider network at its basic form would be limited to 221 understanding the topology and link speeds. More advanced service 222 provider networks may be capable of traffic-engineering and tracking 223 congestion in different parts of their network. However, they are 224 fundamentally incapable of measuring end systems or end-to-end 225 behaviour in paths that cross multiple networks. 227 As a result of the motive conflict and lack of information, any 228 "oracle" style design [RIPE.feldmann] needs to play a fairly limited 229 role in supplying additional information to the P2P applications. 230 Information from the service provider network can help make an 231 initial guess or to narrow the search for the best peer. But it 232 cannot replace or govern the overall decision that the P2P 233 application needs to make on its own. 235 Having basic support for peer selection in the P2P applications also 236 allows the service providers to focus on improvements in their own 237 network, as opposed to attempting to build tools that try to guide 238 selection of peers across multiple networks. As long as the oracle 239 focuses on increasing the number of peers within the service 240 provider's network, the algorithms in P2P applications can take care 241 of optimizing the connectivity to peers in other networks. 243 3.2. Deployment Considerations 245 Another important consideration is what needs to change in order for 246 a particular solution to be deployed. Some solutions can be deployed 247 unilaterally, some require coordinated action. The coordination may 248 act as a disincentive to build support for a particular solution. 249 For instance, P2P application developers do not invest time in 250 building support for contacting an oracle in the service provider 251 network until it becomes likely that such oracles can actually used 252 in some fraction of networks; the limited development resources are 253 better invested in actions that the developers are in full control of 254 -- for instance in improved peer selection algorithms that do not 255 depend on new infrastructure nodes. Similarly, service providers do 256 not invest in an oracle until there is software that actually uses 257 it. 259 This problem affects the following types of solutions: 261 o Quality of service marking in the host and priority treatment in 262 the network. 264 o Network-assisted P2P peer selection. 266 o Network-assisted congestion control mechanisms. 268 3.3. Availability of Information 270 Section 3.1 discussed how available information affects the way best 271 peer selection can be made to work. But there are other aspects of 272 information availability as well. Specifically, when networks have 273 unilaterally implemented mechanisms that do not align with the 274 motives of P2P applications, the applications have employed 275 information hiding in order to prevent the network from making non- 276 desireable prioritization decisions for them. Eric Rescorla makes 277 the argument that ultimately P2P traffic can be secured and made to 278 resemble other types of traffic, such as VPN traffic. This makes it 279 very hard for the network to de-prioritize or modify P2P traffic 280 [P2PI.rescorla]. It is interesting that many of the solutions in the 281 May 2008 P2PI workshop attempt to increase the amount of information 282 available to the parties, while in reality the converse seems to 283 happen. 285 We would like to suggest that this trend can only be reversed if the 286 motives becomes more aligned between the players. That is, no P2P 287 application will participate in a system designed to restrict P2P 288 traffic. But they may participate in systems that attempt to 289 optimize P2P traffic. 291 4. Conclusions 293 The right incentives are a key to the successful standardization and 294 deployment of any solution in this space. Based on our analysis, we 295 would like to suggest that the following avenues for IETF 296 documentation and standards be looked at: 298 o Improved and/or standardized peer selection algorithms. These can 299 be deployed unilaterally by application developers. 301 o Co-operative designs where service provider networks supply 302 additional information that helps the P2P applications to make a 303 better initial selection of peers. This should only be done as a 304 sub-item to the above one; service provider networks do not have 305 sufficient information or incentives to make the full decision, 306 and attempting to do so would dissuade the P2P applications from 307 using such a system. 309 o Improved and/or standardized congestion control mechanisms 310 suitable for P2P and other "always-on" applications. Again, these 311 can be deployed unilaterally, and IETF can help ensure they 312 algorithms are safe for other traffic in the Internet. Note the 313 difference to quality of service mechanisms that typically require 314 deployment at both ends; the quality of service mechanisms would 315 in many ways be the right solution for this problem, but it is 316 hard to get them deployed and used due to the issues mentioned 317 earlier in this paper. 319 Still, both the co-operative designs and congestion control 320 mechanisms depend on the interest of the P2P application 321 developers and users. The primary incentive from their 322 perspective is the desire to be nice for the user's other traffic. 324 In any case, these items are tactical, short-term efforts. There is 325 an associated longer-term issue where the market place has to learn 326 to provide services without relying on statistical multiplexing. 327 Ultimately, if there is demand for communication services 328 (interactive or not) it should be met with an offering that allows 329 providers to build the infrastructure needed to support it, and still 330 be profitable. Pricing models and service packaging has perhaps even 331 more to do with this than technical solutions. 333 Appendix A. Acknowledgments 335 The author would like to thank Magnus Westerlund and Gonzalo 336 Camarillo for interesting discussions in this problem space. 338 5. Informative References 340 [I-D.briscoe-tsvwg-relax-fairness] 341 Briscoe, B., Moncaster, T., and A. Burness, "Problem 342 Statement: We Don't Have To Do Fairness Ourselves", 343 draft-briscoe-tsvwg-relax-fairness-00 (work in progress), 344 November 2007. 346 [P2PI.daigle] 347 Daigle, L., "Defining Success: Questions for the Future of 348 the Internet and Bandwidth-Intensive Activities", P2PI 349 position paper LLD-P2P-Position-May15.pdf, May 2008. 351 [P2PI.tschofenig] 352 Tschofenig, H. and M. Matuszewski, "Dealing with P2P 353 Traffic in an Operator Network: State of the Art", P2PI 354 position paper p2p-state-of-the-art.pdf, May 2008. 356 [P2PI.hardie] 357 Hardie, T., "Peer-to-peer Traffic and "Unattended 358 Consequences", P2PI position paper hardie - p2pi position 359 paper.rtf, May 2008. 361 [P2PI.rescorla] 362 Rescorla, E., "Notes on P2P Blocking and Evasion", P2PI 363 position paper rescorla-p2pi.pdf, May 2008. 365 [P2PI.shalunov] 366 Shalunov, S., "Users want P2P, we make it work", P2PI 367 position paper BitTorrent-Position-IETF-P2P.pdf, May 2008. 369 [P2PI.moncaster] 370 Moncaster, T., Briscoe, B., and L. Burness, "Is There a 371 Problem with Peer-to-peer Traffic", P2PI position paper Is 372 There a Problem with Peer-to-Peer Traffic.pdf, May 2008. 374 [RIPE.feldmann] 375 Feldmann, A., "ISP-Aided Neighbor Selection in P2P 376 Systems", RIPE presentation at RIPE-56, Berlin, May 2008. 378 [I-D.briscoe-tsvwg-re-ecn-tcp] 379 Briscoe, B., "Re-ECN: Adding Accountability for Causing 380 Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-04 381 (work in progress), July 2007. 383 Author's Address 385 Jari Arkko 386 Ericsson 387 Jorvas 02420 388 Finland 390 Email: jari.arkko@piuha.net 392 Full Copyright Statement 394 Copyright (C) The IETF Trust (2008). 396 This document is subject to the rights, licenses and restrictions 397 contained in BCP 78, and except as set forth therein, the authors 398 retain all their rights. 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 403 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 404 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 405 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Intellectual Property 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org.