p2pi M. Barnes Internet-Draft B. McCormick Intended status: Informational Nortel Expires: November 10, 2008 May 9, 2008 Peer to Peer Infrastructure Considerations draft-barnes-p2pi-workshop-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 November 10, 2008. Abstract This is a position paper as input to the Peer to Peer (P2P) Infrastructure Workshop. It describes some of the most common concerns associated with potential congestion on the Internet due to P2P applications. The document makes some very general recommendations to ameliorate potential problems. Barnes & McCormick Expires November 10, 2008 [Page 1] Internet-Draft P2PI May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Position Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. Other Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Barnes & McCormick Expires November 10, 2008 [Page 2] Internet-Draft P2PI May 2008 1. Introduction This document describes some of the most common concerns associated with potential congestion on the Internet due to P2P applications. The document makes some recommendations to ameliorate potential problems. P2P applications are usually running within a user's home network. They communicate directly with other instances of the same applications running on other home networks. Popular P2P applications will transfer data with dozens of other instances at high and sustained bit rates for sharing large files such as operation system distributions, popular TV shows and movies. The volume of data being shared by P2P users is often sufficient to cause congestion on Internet Service Provider's (ISP's) access networks. ISPs look for solutions to the congestion problem. Figure 1 shows some sample P2P applications. ----------- | Home | | Network |-----------------| ----------- | | | --------------- | | P2P | | DPI and "traffic shaping" | Application | | occurs in the ISP access network today --------------- | | ----------- ------------ ----------- | ISP |-----| Internet | | ISP | | Access | | Backbone |----| Access | | Network | ------------ | Network | ----------- ----------- | | ----------- | ----------- | Home |------------------ | Home | | Network | | Network | ----------- ----------- | | --------------- --------------- | P2P | | P2P | | Application | | Application | --------------- --------------- Barnes & McCormick Expires November 10, 2008 [Page 3] Internet-Draft P2PI May 2008 Figure 1: P2P Applications This document is intended to provoke discussion on the concepts, theories and recommendations described herein. 2. Position Overview P2P traffic is congesting the internet. As applications such as video calls gain momentum on the public internet, as opposed to managed networks, P2P traffic, and in fact HTTP [RFC2616] traffic, will impact the quality of real time streaming data including voice, video and gaming. Many ISPs are engaging in some form of traffic prioritization by way of traffic shaping P2P and other traffic on their networks. These methods are often based on deep packet inspection (DPI) and are of limited long term use as they are based on parsing packet headers, etc. These methods can be subverted without much work. Packet prioritization is a proven solution to maintaining Quality of Service (QoS) for delay sensitive traffic and has been widely deployed on wireless and managed networks. However, users will abuse packet prioritization if they have no motivation to behave correctly. Similarly, ISP peering, where priority packets transit a 3rd party network, has no motivation to respect packet priority. Unless ISPs are willing to invest indefinitely in network capacity build out, there needs to be some incentive to avoid the high levels of traffic generated by users at the far end of the spectrum. Alternatively, real time applications will become more unreliable. Carriers and vendors need to deploy DiffServ Code Point (DSCP) [RFC2474] [RFC2475] enabled equipment. User pricing agreements need to charge a premium for real time traffic priorities and provide a discount for high volume best effort priorities, as do peering agreements. 3. Other Considerations In general there seem to be four possible outcomes to continuing Internet growth: a. Without sufficient network build out and no traffic prioritization, Internet congestion increases until real time applications no longer function and non-real time applications are impacted. Barnes & McCormick Expires November 10, 2008 [Page 4] Internet-Draft P2PI May 2008 b. Network build out continues at a rate so that network congestion is a thing of the past and no traffic prioritization is necessary. c. Networks implement traffic prioritization and charge premiums for real time traffic. Similarly, discounts could be offered for low priority traffic. d. Operators exercise increasing levels of control over their access networks and find means to restrict traffic to white listed traffic approved by the operator. e. Networks implement a model whereby they charge equally independent of the application, but may simply charge per volume of packets. In the ideal world, option b) would take place. However, option b) doesn't provide any clear means for operators to grow, or even maintain, their business model. Deploying more capacity at the edge of the Internet is expensive and operators will expect to have some direct value proposition for this activity. Options a) and d) would change the internet in ways that limit innovation and growth and we consider them to be wholly undesirable. Option e) is already implemented by some ISPs today. Although, it is not uncommon for ISPs to also offer unlimited packages, thus this model may not be as effective overall. In cases where there is sufficient network capacity, charging by volume could be used to manage aggregate volume. Option c), may be a more pragmatic choice in cases where there may be limitations to network capacity. Many operators today are implementing deep packet inspection as a means of prioritizing traffic on their networks. However, deep packet inspection has limited long term viability. It is one thing to identify traffic based on packet headers, it's another thing entirely to try and determine if peer to peer traffic is tunnelled inside, for example, jpeg images transported on HTTP. More complex approaches could be applied to detect peer to peer traffic, such as traffic analysis. Home networks with dozens of simultaneous connections to other home networks are probably engaging in peer to peer applications. This method of traffic prioritization would be more difficult to subvert, however it would also be more difficult to implement at line speeds. Rather than relying on such ad hoc methods of traffic prioritization, it would be better to use designed in traffic prioritization such as DSCP. This approach also allows operators to charge for use and will Barnes & McCormick Expires November 10, 2008 [Page 5] Internet-Draft P2PI May 2008 help address public perception that traffic shaping is bad. Peer to peer traffic has been growing steadily for the last 10 years and shows no signs of slowing. P2P has been responsible for significant innovation in the application space, and thus is likely to continue to be very popular. Any type of bulk data transfer will impact real-time traffic. There's no reason that FTP and HTTP transfers should not be subject to a prioritization mechanism. P2P applications tend to be worse today because it is easy for users to leave them running 24/7. However, there's nothing to stop a user from running a bot program which downloads high volumes of traffic from HTTP or FTP servers. Network operators have already lost control of the "pipe". It's unreasonable for an operator to expect to be able to directly control the applications that are transferring data over their network. Telephone companies today are not allowed to control the type of traffic over their network. Imagine a telephone company implementing, for example, an anti-Italian or anti-Portuguese policy and dropping all calls in these languages! Similarly, ISPs should not be in a position to white list or black list specific types of traffic. 4. Summary of Recommendations At this point, the authors do not see specific new protocol work related to this problem in IETF. However, the authors suggest that using the input and discussion from the p2pi workshop, guidelines and recommendations, perhaps even a Best Current Practice [RFC2026] would be of benefit to the community. 5. Acknowledgements The authors appreciate the input and comments from Francois Audet and Marcus Leech. 6. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, Barnes & McCormick Expires November 10, 2008 [Page 6] Internet-Draft P2PI May 2008 December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [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. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. Authors' Addresses Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX Email: mary.barnes@nortel.com Bill McCormick Nortel 3500 CARLING AVENUE Ottawa, Ontario Email: billmcc@nortel.com Barnes & McCormick Expires November 10, 2008 [Page 7] Internet-Draft P2PI May 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. Barnes & McCormick Expires November 10, 2008 [Page 8]