Re: [p2pi] [tana] TANA proposed charter

Laird Popkin <> Wed, 22 October 2008 17:51 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9C8073A69B2; Wed, 22 Oct 2008 10:51:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 079713A69B2; Wed, 22 Oct 2008 10:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id umJrMcn8FIRE; Wed, 22 Oct 2008 10:51:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 802B43A6970; Wed, 22 Oct 2008 10:51:45 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 57A75E10D2E; Wed, 22 Oct 2008 13:53:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JT1wnI-wqauz; Wed, 22 Oct 2008 13:52:50 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id 1660FE10D3F; Wed, 22 Oct 2008 13:52:50 -0400 (EDT)
Date: Wed, 22 Oct 2008 13:52:50 -0400 (EDT)
From: Laird Popkin <>
To: Stanislav Shalunov <>
Message-ID: <>
In-Reply-To: <>
MIME-Version: 1.0
X-Originating-IP: []
Cc: " Area" <>,,
Subject: Re: [p2pi] [tana] TANA proposed charter
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Nice job.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Stanislav Shalunov" <>
To:,, " Area" <>
Sent: Wednesday, October 22, 2008 12:45:52 PM (GMT-0500) America/New_York
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


Transport Area Director(s):
* Magnus Westerlund <>
* Lars Eggert <>

Transport Area Advisor:
* Lars Eggert <>

Mailing Lists:

General Discussion:
To Subscribe:
In Body: (un)subscribe

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.

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  

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  

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.

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


Transport for Advanced Networking Applications (TANA) Problem Statement

No Requests for Comments

Stanislav Shalunov

p2pi mailing list
p2pi mailing list