Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational July 29, 2008 Expires: January 30, 2009 Incentives and Deployment Considerations for P2PI Solutions draft-arkko-p2pi-incentives-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 30, 2009. Abstract Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to- peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution. Arkko Expires January 30, 2009 [Page 1] Internet-Draft P2P and Incentives July 2008 1. Introduction Peer-to-peer (P2P) networking has been cited as the leading consumer of network bandwidth in networks serving private subscribers. This is by itself not a problem, as the network providers are in the business of providing a service to their customers, including the ones that employ P2P tools. However, the issue is whether P2P traffic causes undue congestion and reduced level of service for other customers in the network [I-D.briscoe-tsvwg-relax-fairness]. Historically, the Internet service provider market has developed for interactive services where the bandwidth requirements for each user vary significantly from over time. This allowed the service providers to employ statistical multiplexing. At the same time, the nominal link speeds have been a major factor in marketing Internet service. But during the last few years, the nature of the traffic has changed from interactive to more always-on type traffic, for instance from P2P applications. As a result, statistical multiplexing is no longer effective, and service providers are finding that a large sets of users are actually trying to utilize their full link speed at all times. This is making the service providers either increase the capacity of their networks to match the changing traffic mix and increasingly high broadband service speeds, or find other ways to deal with the problems. It is important to see that these problems are not limited to P2P tools [P2PI.daigle]. Indeed, not even all P2P applications have these problems. Some forms of video communication exhibit the same problems that large file sharing P2P applications do [P2PI.hardie]. And as the Internet applications evolve, we expect to see new forms of traffic with these issues. In the remainder of this paper, we assume any bandwidth-intensive, semi-permanently running application that may or may not attempt to be friendly with other network usage. The fairness problem can present itself in various ways. For instance, users opening multiple transport sessions may get a disproportionate share of a congested link. Permanent, high bandwidth sessions may slow down the ramp-up of short-term, interactive sessions. Or some users may utilize a transit link far more than others, resulting in these users gaining a larger share of the transit costs that the provider has to pay. These problems are not just abstract issues. There has been highly publicized debates about what forms of traffic management are acceptable for network providers. In reality, network providers already employ a number of techniques [P2PI.tschofenig]. Solutions addressing issues in this space have been worked on by network providers, vendors, and researchers. This paper looks at the Arkko Expires January 30, 2009 [Page 2] Internet-Draft P2P and Incentives July 2008 different classes of solutions in Section 2 and analyzes them based on the incentives of the involved parties in Section 3. The key issue is finding a solution that provides immediate benefits to everyone who needs to add new mechanisms or equipment. Another key issue is the information available to different parties. This leads us to make conclusions in Section 4. 2. Solution Classes A number of solutions have already been deployed to mitigate issues caused by the changed traffic pattern. Other solutions are actively being worked on. We divide the solutions in three rough classes, based partially on similar classifications in [P2PI.tschofenig] [P2PI.moncaster]: Contractual These solutions are based on choosing pricing models and contractual conditions that persuade users to avoid always-on traffic. For instance, volume-based accounting can be employed, or the contracts of the heaviest users can be discontinued. Voluntary changes in applications These solutions are based on some change of behaviour in the applications, leading to taking other users better into account, reducing congestion or the use of expensive links, and so on. Some of the solutions in this category include: * Indicating the desired quality of service, so that interactive and always-on applications can be distinguished in the network [P2PI.moncaster]. This assumes that there is a basic level of quality of service filtering capabilities in the network. * Making decisions with better information about the network topology and cost. For instance, algorithms that P2P applications use to determine which peers to talk to can probably be improved. One particular class of improvements involves "oracles" in the service provider network to help applications determine the most likely peers with good connectivity. For instance, peers that are in the local service provider network vs. behind an expensive and/or congested transit service provider. * New congestion control mechanisms. For instance, BitTorrent has gotten positive results from their new algorithm Arkko Expires January 30, 2009 [Page 3] Internet-Draft P2P and Incentives July 2008 [P2PI.shalunov]. Another example is Bob Briscoe's re-ECN mechanism [I-D.briscoe-tsvwg-re-ecn-tcp], which allows hosts and networks to co-operate in the treatment of congestion, and allows networks to treat different users in a fair manner. Network-based mechanisms These mechanisms are implemented solely in the network. Examples include: * Prioritization, slowdown, or even blocking of traffic based on packet header information. Relatively complicated designs that peek further into the packet, Deep Packet Inspection (DPI) have also been deployed. Priorities can also be set based on user accounting information, e.g., traffic shaping heavy users during a rush hour. * Changing the "scheduling algorithm", by attempting to complete the short jobs first everyone's performance will improve. Similar techniques as discussed above are needed to determine which jobs are "short" and "long", however. * Building caches and peer-to-peer network components in the service provider network. 3. Incentives This section discusses motives, deployment considerations, and how information available to the different parties affects the incentives. 3.1. Motives For any solution to be adopted the involved parties have to have compatible motives. This is not always trivial, because the parties may either optimize for different goals, or because there is room for malicious behaviour. For instance, one type of a quality-of-service solution involves voluntary marking of packets by applications and subsequent differentiated treatment of these packets by the network. In this case the motives of well-behaving users and service providers are similar: both want interactive applications to be given more priority, while allowing always-on batch applications to run in the background, and take as much bandwidth as is available. However, if the prioritization happens across multiple users, this also implies that a lower priority marking has the potential to reduce the user's Arkko Expires January 30, 2009 [Page 4] Internet-Draft P2P and Incentives July 2008 share of the overall throughput. Clever users can distort the system by claiming to run only interactive applications. A tragedy of the commons follows: The optimal strategy from the point of view of the entire group of users would be to correctly classify traffic. But from the point of an individual user a better strategy would be to lie. Note that no misbehaviour is needed from a human user for this to happen. It is enough that the user runs applications that do this. And if such applications appear to produce better results than other applications, the user has an incentive to use them. Having said this, past experience tells us that a vast majority of networking software plays by the rules. Attempts to improve or bypass TCP congestion control are relatively rare, for instance. An example where the motives themselves may be conflict is the co- operation between P2P applications and service providers to determine the "best" peers to connect to. The definition of "best" from the P2P client perspective is a peer that has the highest possible actual transfer rate. But the service provider is more interested in minimization of their costs and overall network congestion. This may or may not coincide with the client's desires. For instance, a service provider may prefer a local peer with a slow access link over a remote peer that is connected via an expensive transit connection. While not part of the incentives, the available information to the different parties plays an interesting role as well. It can be expected that P2P nodes are capable of measuring actual transfer rates across the end-to-end path, including the behaviour of the end systems. P2P applications might even be able to accumulate this information from multiple clients and over time. In contrast, the service provider network at its basic form would be limited to understanding the topology and link speeds. More advanced service provider networks may be capable of traffic-engineering and tracking congestion in different parts of their network. However, they are fundamentally incapable of measuring end systems or end-to-end behaviour in paths that cross multiple networks. As a result of the motive conflict and lack of information, any "oracle" style design [RIPE.feldmann] needs to play a fairly limited role in supplying additional information to the P2P applications. Information from the service provider network can help make an initial guess or to narrow the search for the best peer. But it cannot replace or govern the overall decision that the P2P application needs to make on its own. Having basic support for peer selection in the P2P applications also allows the service providers to focus on improvements in their own Arkko Expires January 30, 2009 [Page 5] Internet-Draft P2P and Incentives July 2008 network, as opposed to attempting to build tools that try to guide selection of peers across multiple networks. As long as the oracle focuses on increasing the number of peers within the service provider's network, the algorithms in P2P applications can take care of optimizing the connectivity to peers in other networks. 3.2. Deployment Considerations Another important consideration is what needs to change in order for a particular solution to be deployed. Some solutions can be deployed unilaterally, some require coordinated action. The coordination may act as a disincentive to build support for a particular solution. For instance, P2P application developers do not invest time in building support for contacting an oracle in the service provider network until it becomes likely that such oracles can actually used in some fraction of networks; the limited development resources are better invested in actions that the developers are in full control of -- for instance in improved peer selection algorithms that do not depend on new infrastructure nodes. Similarly, service providers do not invest in an oracle until there is software that actually uses it. This problem affects the following types of solutions: o Quality of service marking in the host and priority treatment in the network. o Network-assisted P2P peer selection. o Network-assisted congestion control mechanisms. 3.3. Availability of Information Section 3.1 discussed how available information affects the way best peer selection can be made to work. But there are other aspects of information availability as well. Specifically, when networks have unilaterally implemented mechanisms that do not align with the motives of P2P applications, the applications have employed information hiding in order to prevent the network from making non- desireable prioritization decisions for them. Eric Rescorla makes the argument that ultimately P2P traffic can be secured and made to resemble other types of traffic, such as VPN traffic. This makes it very hard for the network to de-prioritize or modify P2P traffic [P2PI.rescorla]. It is interesting that many of the solutions in the May 2008 P2PI workshop attempt to increase the amount of information available to the parties, while in reality the converse seems to happen. Arkko Expires January 30, 2009 [Page 6] Internet-Draft P2P and Incentives July 2008 We would like to suggest that this trend can only be reversed if the motives becomes more aligned between the players. That is, no P2P application will participate in a system designed to restrict P2P traffic. But they may participate in systems that attempt to optimize P2P traffic. 4. Conclusions The right incentives are a key to the successful standardization and deployment of any solution in this space. Based on our analysis, we would like to suggest that the following avenues for IETF documentation and standards be looked at: o Improved and/or standardized peer selection algorithms. These can be deployed unilaterally by application developers. o Co-operative designs where service provider networks supply additional information that helps the P2P applications to make a better initial selection of peers. This should only be done as a sub-item to the above one; service provider networks do not have sufficient information or incentives to make the full decision, and attempting to do so would dissuade the P2P applications from using such a system. o Improved and/or standardized congestion control mechanisms suitable for P2P and other "always-on" applications. Again, these can be deployed unilaterally, and IETF can help ensure they algorithms are safe for other traffic in the Internet. Note the difference to quality of service mechanisms that typically require deployment at both ends; the quality of service mechanisms would in many ways be the right solution for this problem, but it is hard to get them deployed and used due to the issues mentioned earlier in this paper. Still, both the co-operative designs and congestion control mechanisms depend on the interest of the P2P application developers and users. The primary incentive from their perspective is the desire to be nice for the user's other traffic. In any case, these items are tactical, short-term efforts. There is an associated longer-term issue where the market place has to learn to provide services without relying on statistical multiplexing. Ultimately, if there is demand for communication services (interactive or not) it should be met with an offering that allows providers to build the infrastructure needed to support it, and still be profitable. Pricing models and service packaging has perhaps even more to do with this than technical solutions. Arkko Expires January 30, 2009 [Page 7] Internet-Draft P2P and Incentives July 2008 Appendix A. Acknowledgments The author would like to thank Magnus Westerlund and Gonzalo Camarillo for interesting discussions in this problem space. 5. Informative References [I-D.briscoe-tsvwg-relax-fairness] Briscoe, B., Moncaster, T., and A. Burness, "Problem Statement: We Don't Have To Do Fairness Ourselves", draft-briscoe-tsvwg-relax-fairness-00 (work in progress), November 2007. [P2PI.daigle] Daigle, L., "Defining Success: Questions for the Future of the Internet and Bandwidth-Intensive Activities", P2PI position paper LLD-P2P-Position-May15.pdf, May 2008. [P2PI.tschofenig] Tschofenig, H. and M. Matuszewski, "Dealing with P2P Traffic in an Operator Network: State of the Art", P2PI position paper p2p-state-of-the-art.pdf, May 2008. [P2PI.hardie] Hardie, T., "Peer-to-peer Traffic and "Unattended Consequences", P2PI position paper hardie - p2pi position paper.rtf, May 2008. [P2PI.rescorla] Rescorla, E., "Notes on P2P Blocking and Evasion", P2PI position paper rescorla-p2pi.pdf, May 2008. [P2PI.shalunov] Shalunov, S., "Users want P2P, we make it work", P2PI position paper BitTorrent-Position-IETF-P2P.pdf, May 2008. [P2PI.moncaster] Moncaster, T., Briscoe, B., and L. Burness, "Is There a Problem with Peer-to-peer Traffic", P2PI position paper Is There a Problem with Peer-to-Peer Traffic.pdf, May 2008. [RIPE.feldmann] Feldmann, A., "ISP-Aided Neighbor Selection in P2P Systems", RIPE presentation at RIPE-56, Berlin, May 2008. [I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., "Re-ECN: Adding Accountability for Causing Arkko Expires January 30, 2009 [Page 8] Internet-Draft P2P and Incentives July 2008 Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-04 (work in progress), July 2007. Author's Address Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Arkko Expires January 30, 2009 [Page 9] Internet-Draft P2P and Incentives July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Arkko Expires January 30, 2009 [Page 10]