[p2pi] TANA proposed charter

[Stanislav Shalunov <[e-mail]>]

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

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