Re: [p2pi] TANA proposed charter

[Reinaldo Penno <[e-mail]>]

I support this WG and intend to submit a draft on P2P multiple connections
before the deadline.

Thanks,

Reinaldo


On 10/21/08 6:17 AM, "Stanislav Shalunov" <[e-mail]> 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 <[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.t
> xt
> 
> No Requests for Comments
> 
> 
> 
>  
> --
>  Stanislav Shalunov <http://shlang.com/>
> 
>   <http://feeds.feedburner.com/~r/shlang/~6/1>
>  
> 
> 
> 
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi