At the BoF in Dublin, we observed strong interest and consensus that the
TANA work should go forward as a working group. Does the following
proposed charter, based on the BoF description, capture what the community was
interested in?
Techniques for Advanced Networking Applications (TANA)
WG
Chair(s):
TBD
Transport Area Director(s):
* Magnus
Westerlund <
magnus.westerlund at ericsson.com>
*
Lars Eggert <
lars.eggert at nokia.com>
Transport
Area Advisor:
* Lars Eggert <
lars.eggert at nokia.com>
Mailing
Lists:
General Discussion:
tana at ietf.orgTo Subscribe:
tana-request at ietf.orgIn Body:
(un)subscribe
Archive:
http://www.ietf.org/mail-archive/web/tana/Description
of Working Group:
The TANA WG is chartered to standardize a congestion
control mechanism that should saturate the bottleneck, maintain low delay, and
yield to standard TCP.
Applications that transmit large amounts of data
for a long time with congestion-limited TCP, but without ECN fill the buffer
at the head of the bottleneck link. This increases the delay experienced by
other applications. In the best case, with an ideally sized buffer of one RTT,
the delay doubles. In some cases, the extra delay may be much larger. This is
a particularly acute and common case is when P2P applications upload over thin
home uplinks: delays in these cases can sometimes be of the order of
seconds.
The IETF's standard end-to-end transport protocols have not
been designed to minimize the extra delay introduced by them into
the
network. TCP, as a side effect of filling the buffer until it
experiences drop-tail loss, effectively maximizes the delay. While this works
well for applications that are not delay-sensitive, it harms interactive
applications that share the same bottleneck. VoIP and games are particularly
affected, but even web browsing may become problematic.
TANA is a
transport-area WG that will focus on broadly applicable techniques that allow
large amounts of data to be consistently transmitted without substantially
affecting the delays experienced by other users and applications.
The
WG will work on the following:
(1) An experimental congestion control
algorithm for less-than-best-effort "background" transmissions, i.e., an
algorithm that attempts to scavenge otherwise idle bandwidth for its
transmissions in a way that minimizes interference with regular best-effort
traffic.
Desired features of such an algorithm are:
* saturate the
bottleneck,
* eliminate long standing queues and thus keep delay low when
no other traffic is present,
* quickly yield to regular best-effort traffic
that uses standard TCP congestion control,
* add little to the queueing
delays induced by TCP traffic,
* operate well in today's typical networks
with FIFO queueing with drop-tail discipline,
* where available, use
explicit congestion notification (ECN), active queue management (AQM), and/or
end-to-end differentiated services (DiffServ).
Application of this
algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to
occur in the working groups that maintain those protocols.
(2) A
document that clarifies the current practices of application design and
reasons behind them and discusses the tradeoffs surrounding the use of many
concurrent transport connections to one peer and/or to different
peers.
Standard Internet congestion control result in different
transport connections sharing bottleneck capacity. When an application uses
several unchoked and not rate-limited transport connections to transfer
through a bottleneck, it may obtain a larger fraction of the bottleneck than
if it had used fewer connections. Although capacity is the most commonly
considered bottleneck resource, middlebox state table entries are also an
important resource for an end system communication. Other resource types may
exist, and the guidelines are expected to comprehensively discuss
them.
Applications use a variety of techniques to mitigate these
concerns. These techniques have not always been reviewed by the IETF and
their interaction with TCP dynamics is poorly understood. The WG
document the known techniques, discussing the consequences and, where
appropriate, provide guidance to application designers.
(3) The WG will
discuss how to best take into account prior work in the area. The
outcome will be either incorporated into the document specifying the
experimental congestion control algorithm or into a separate document
summarizing prior work.
Goals and Milestones
TBD
Submit "Multiple Transport Connections in Applications Design" to the
IESG for consideration as an Informational RFC
TBD Submit "Transport
for Advanced Networking Applications (TANA)" to the IESG for consideration as
an Experimental RFC
Internet-Drafts
Transport for Advanced
Networking Applications (TANA) Problem Statement
http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txtNo
Requests for Comments
