Re: [p2pi] [tana] TANA proposed charter

[<[e-mail]>]

This is looking pretty good to me. Couple of minor changes inline...

Toby

____________________________________________________________________
Toby Moncaster, <[e-mail]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone] 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Stanislav Shalunov
> Sent: 22 October 2008 17:46
> To: [e-mail]; [e-mail]; [e-mail] Area
> Subject: Re: [p2pi] [tana] TANA proposed charter
> 
> A refreshed working copy of the draft charter.  I've attempted to
> capture and reconcile the edits and clarify point (2).
> 
> We'll need to change the name, but it's not yet reflected because a
> new one hasn't been selected.
> 
> -- 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 AQM, fill the buffer at the head
> of the bottleneck link. With FIFO queue, this increases the delay
> experienced by other applications. With 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.
> 

" With FIFO queue, this increases the delay experienced by other
applications. With buffer of one RTT, the delay doubles."

--> " With FIFO queues, this increases the delay experienced by other
applications. With buffers of the order of one RTT, the delay doubles."

> 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 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 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 TCP connections to one destination and/or
> to different destinations.
> 
> Applications routinely open multiple TCP connections.  For example,
> P2P applications maintain connections to a number of different peers
> while web browsers perform concurrent downloads from the same web
> server.  Application designers pursue different goals when doing so:
> P2P apps need to maintain a well-connected mesh in the swarm while web
> browsers mainly use multiple connections to parallelize requests that
> involve application latency on the web server side.  The IETF
> transport area community is concerned about this practice, because
> standard Internet congestion control results in different transport
> connections sharing bottleneck capacity. When an application uses
> several non-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.
> 

It would be nice to add something about the fact that TCP strongly
favours long-running flows over shorter flows and that this further
exacerbates the problems of capacity sharing. Not sure if this should go
here or in the first work item?

> 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 will
> 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
> 
> 
> 
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi