Re: [p2pi] TANA proposed charter

["Livingood, Jason" <[e-mail]>]

Good charter so far.  Agree that we need a better name.  I intend to
participate as a document author, document contributor, and a reviewer.
 
Jason


________________________________

	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: [p2pi] 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-statemen
t-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