Network Working Group S. Shalunov
Internet-Draft BitTorrent
Intended status: Standards Track July 14, 2008
Expires: January 15, 2009
Transport for Advanced Networking Applications (TANA) Problem Statement
draft-shalunov-tana-problem-statement-01.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 15, 2009.
Shalunov Expires January 15, 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 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 15, 2009 [Page 2]
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 15, 2009 [Page 3]
Internet-Draft TANA Problem Statement July 2008
2. Congestion control that minimizes delay and a UDP-based 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.
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.
Shalunov Expires January 15, 2009 [Page 4]
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. 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
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 15, 2009 [Page 5]
Internet-Draft TANA Problem Statement July 2008
4. Security Considerations
None.
Shalunov Expires January 15, 2009 [Page 6]
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 15, 2009 [Page 7]
Internet-Draft TANA Problem Statement July 2008
Author's Address
Stanislav Shalunov
BitTorrent
201 Mission St, Suite 900
San Francisco, CA 94110
US
Email: shalunov@bittorrent.com
URI: http://shlang.com/
Shalunov Expires January 15, 2009 [Page 8]
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 15, 2009 [Page 9]