Network Working Group S. Shalunov Internet-Draft July 7, 2008 Intended status: Standards Track Expires: January 8, 2009 Transport for Advanced Networking Applications (TANA) Problem Statement draft-shalunov-tana-problem-statement-00.txt 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 8, 2009. Shalunov Expires January 8, 2009 [Page 1] Internet-Draft TANA Problem Statement July 2008 Abstract The IETF P2PI workshop conducted in the end of May 2008 at MIT in Boston has identified a number of potential documents for the IETF to work on. One is a transport protocol with congestion control mechanism that enables an advanced networking application to minimize the extra delay it induces in the bottleneck while implementing an end-to-end version of scavenger service. At least one such protocol has now been implemented by a major peer-to-peer application and deployed in the wild with favorable results. Another is a document that addresses community concerns about the use of multiple transport connections by peer-to-peer applications, both when these connections run to the same peer and to different peers. These two items appear to fall within the Transport area, but not within the charter of any existing working group. It is not obvious what WG's charter could be naturally extended to encompass these two items. The TANA BoF is held to explore the problem space, gauge the interest in the problems within the Transport area, and to see if the community and the area directors believe that it makes sense to form a TANA working group within the Transport area to chartered to work on (1) standardizing end-to-end congestion control that enables advanced application to minimize the delay they introduce into the network and a protocol using it and (2) a document describing the current practice of peer-to-peer apps' use of multiple transport connections and recommendations in this space. Shalunov Expires January 8, 2009 [Page 2] Internet-Draft TANA Problem Statement July 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Congestion control that minimizes delay and a protocol using it . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use of multiple transport connections by peer-to-peer applications . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Shalunov Expires January 8, 2009 [Page 3] Internet-Draft TANA Problem Statement July 2008 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Shalunov Expires January 8, 2009 [Page 4] Internet-Draft TANA Problem Statement July 2008 2. Congestion control that minimizes delay and a protocol using it The standard congestion control in TCP is based on loss and has not been designed to drive delay to any given value. Because TCP needs losses to back off, when a FIFO bottleneck lacks AQM, TCP fills the buffer, effectively maximizing possible delay. Large number of the thinnest links in the Internet, particularly most uplinks of home connections, lack AQM. They also frequently contain enough buffer space to get delays into hundreds of milliseconds and even seconds. There is no benefit to having delays this large, but there are very substantial drawbacks for interactive applications: games and VoIP become impossible and even web browsing becomes very slow. It is desirable to have a congestion control mechanism that would allow to keep the latency across the congested bottleneck low even as it is saturated. This would allow applications that send large amounts of data, particularly upstream on home connections, such as peer-to-peer application, to operate without destroying the experience in interactive applications. It is possible to design congestion control mechanisms that take advantage of delay measurements and can back off before loss occurs. One such mechanism has been deployed by BitTorrent in the wild with the BitTorrent DNA client. This mechanism not only allows to keep delay across a bottleneck low, but also yields quickly in the presence of competing traffic with loss-based congestion control. Standardization of a congestion control mechanism that meets these design objectives would enable other advanced networking applications to better get out of the way of interactive apps. Shalunov Expires January 8, 2009 [Page 5] Internet-Draft TANA Problem Statement July 2008 3. Use of multiple transport connections by peer-to-peer applications The community is concerned about the possible use of multiple transport connections by peer-to-peer clients, particularly if the goal of such use is to circumvent fairness mechanisms in TCP. Peer-to-peer clients are designed to open connections to multiple other peers to organize a well-connected mesh. There is confusion about whether they are also designed to open multiple connections to the same peer to get an unfair share of bottleneck capacity. (I am personally not familiar with examples of P2P clients that are designed to open multiple connections to the same destination.) While the use of multiple transport connections, even to the same destination, has been common since the advent of the web browser, peer-to-peer applications are believed by some to open an unusually large number of connections and send data for particularly long periods of time. The most common P2P protocol, BitTorrent, uses a mechanism called "choking" to limit the number of connections that actually send and receive data. Many more connections are open that used for data. Most connections are only used for small pieces of metadata. This further complicates the analysis. Both the IETF transport community and the designers of P2P apps would benefit from clarity produced by a document that would (1) describe the current practice of multiple connections use by peer-to-peer apps and (2) make recommendations about the best such practices. Shalunov Expires January 8, 2009 [Page 6] Internet-Draft TANA Problem Statement July 2008 4. Security Considerations None. Shalunov Expires January 8, 2009 [Page 7] Internet-Draft TANA Problem Statement July 2008 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Shalunov Expires January 8, 2009 [Page 8] Internet-Draft TANA Problem Statement July 2008 Author's Address Stanislav Shalunov Shalunov Expires January 8, 2009 [Page 9] Internet-Draft TANA Problem Statement 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. Shalunov Expires January 8, 2009 [Page 10]