Re: [p2pi] TANA proposed charter
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2pi] TANA proposed charter
I think that over all this is a decent charter and I support and hope
to participate in this work. Some comments and nits follow.
(I, by the way, have no trouble with the proposed name.)
Regards
Marshall
On Oct 21, 2008, at 9:17 AM, Stanislav Shalunov wrote:
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?
Thanks, -- Stas
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.org
To Subscribe: tana-request at ietf.org
In 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.
Should this read "should saturate bottlenecks while retaining
fairness" ?
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
s/ECN/ECN, /
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.
Are there FEC issues here ? I see possibly a couple :
- FEC may have fairness / congestion control issues in this context as
it involves bandwidth usage that scales with the underlying
application, and yet may be separately controlled. In general it is
assumed that, say, a 30% FEC is "OK" if the underlying application
uses congestion control, but if you are trying to saturate a
bottleneck that may not be true if the FEC is added on top of the
saturating flow.
- in a scavenger service it might be very useful to have a mechanism
to distinguish between control and other critical data, which might
benefit from FEC, and the mass of the data, which might not need or
warrant FEC. Some standardized means of signaling this might be useful.
(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.
The above wording is not clear to me.
Are you referring to TCP in the above sentence ? If so, be specific.
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,
s/The WG document/The WG will document/
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.txt
No Requests for Comments
--
Stanislav Shalunov
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
