|
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 16, 2009.
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 chartered to work on
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
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.
While a number of delay-based congestion control mechanisms have been proposed, they were generally not designed to minimize the delay induced in the network.
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.
To deploy a protocol using such congestion control in today's Internet, the protocol needs to be designed to work with existing deployed NATs, firewalls, and other middleboxes. This limits the choices of the transport framing to TCP and UDP. Modifying TCP is out of scope for TANA, because it is a more ambitious project while advanced applications can use a special protocol to talk among instances of themselves. This leaves us with UDP as the underlying framing for the protocol.
In addition to direct and immediate benefits for advanced application, such congestion control would lay the foundation for a possible future evolution of the Internet where loss is not part of the designed behavior and delay is minimized.
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. For example, with just a single connection per peer, peers would pair off and be quickly out of trading material; with two connections, peers would form long chains that still promote segmentation and are fragile. There is confusion about whether peer-to-peer applications 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, for any purpose.)
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 and can create the impression that the peer uses many more connections than it actually does.
Both the IETF transport community and the designers of P2P apps would benefit from clarity produced by a document that would
None.
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| Stanislav Shalunov | |
| BitTorrent | |
| 201 Mission St, Suite 900 | |
| San Francisco, CA 94110 | |
| US | |
| Email: | shalunov@bittorrent.com |
| URI: | http://shlang.com/ |
Copyright © 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.
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.