Re: [p2pi] [tsv-area] TANA proposed charter

[Bruce Davie <[e-mail]>]

  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: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Stanislav Shalunov
>> Sent: Tuesday, October 21, 2008 9:17 AM
>> To: [e-mail]; [e-mail]; 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 <[e-mail]>
>> * Lars Eggert <[e-mail]>
>>
>> Transport Area Advisor:
>> * Lars Eggert <[e-mail]>
>>
>> Mailing Lists:
>>
>> General Discussion: [e-mail]
>> To Subscribe: [e-mail]
>> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi