Re: [p2pi] [tsv-area] TANA proposed charter
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2pi] [tsv-area] TANA proposed charter
I'll start by saying that I support the WG and think the new charter
is pretty good. I have a few suggestions for small changes.
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.
Replace ECN with Active Queue Management (AQM)
This increases the
delay experienced by other applications.
It would be more accurate to say "In the absence of any form of
isolation in the queues, this increases..."
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.
Since there isn't complete agreement on the ideal size of a buffer,
just say:
"If the buffer size is one RTT, the delay doubles...."
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.
[snip]
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,
perhaps it would be more precise to say:
"quickly yield to traffic sharing the same bottleneck queue 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,
suggest deleting "today's typical"
* where available, use explicit congestion notification (ECN),
active queue management (AQM), and/or end-to-end
differentiated services (DiffServ).
[snip]
(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.
This is just a bit confusingly worded and could be interpreted very
broadly. I would suggest:
"(2) A document that discusses the
tradeoffs surrounding the use of many concurrent transport
connections to one peer and/or to different peers and recommends best
practices for applications in this regard."
Finally, I hate the name, because it is so completely undescriptive of
the WG. I like all of Wesley's suggestions better, MILT probably being
the best.
Bruce
On Oct 21, 2008, at 10:12 AM, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
The charter, as written looks reasonable to me. I just hate the name
:).
Even though you explained it before, "Advanced Network Applications"
still bothers me as it's completely unspecific. Furthermore, I think
that "Techniques" isn't well-scoped enough to limit the work properly
as it seems to be focused on congestion control techniques, and not
NAT traversal techniques, search techniques, etc.
The way that the problem statement was described, I think what's
really
meant is "bulk transfer applications that want to be a good neighbor
to
real-time or other applications". I guess the challenge is that this
doesn't produce a pronouncable acronym like TANA :).
It should really be something like:
"Minimizing Impact of Large Transfers" (MILT)
"Concurrent Realtime And Bulk Applications" (CRABA)
"Fast Transfers Adding Minimal Latency" (FTAML)
"Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) --
probably not a good one as it looks too much like "barfing" :)
But if nobody else has a problem with the TANA name, I'll keep my
mouth
shut so we don't waste time and energy. There are bigger fish to fry!
-----Original Message-----
From: tsv-area-bounces at ietf.org
[mailto:tsv-area-bounces at ietf.org] On Behalf Of Stanislav Shalunov
Sent: Tuesday, October 21, 2008 9:17 AM
To: tana at ietf.org; p2pi at ietf.org; TSV Area
Subject: [tsv-area] TANA proposed charter
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.
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.txt
No Requests for Comments
--
Stanislav Shalunov <http://shlang.com/>
Hacking Startups <http://feeds.feedburner.com/~r/shlang/~6/1>
_______________________________________________
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.
