Re: [p2pi] [tana] TANA proposed charter

<> Thu, 23 October 2008 09:59 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9133B3A6959; Thu, 23 Oct 2008 02:59:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76B9D3A6870; Thu, 23 Oct 2008 02:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.231
X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O9vSfqdD+pe0; Thu, 23 Oct 2008 02:59:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E77F73A6959; Thu, 23 Oct 2008 02:59:24 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 10:57:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 23 Oct 2008 10:57:13 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [p2pi] [tana] TANA proposed charter
Thread-Index: Ack0Zb6SCDlyQ/JWR2e2GDvAyNAPZgAjrBRw
References: <><><><> <>
From: <>
To: <>, <>, <>, <>
X-OriginalArrivalTime: 23 Oct 2008 09:57:16.0932 (UTC) FILETIME=[BB369C40:01C934F5]
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

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


Toby Moncaster, <> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> -----Original Message-----
> From: [] On Behalf
> Stanislav Shalunov
> Sent: 22 October 2008 17:46
> To:;; 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):
> Transport Area Director(s):
> * Magnus Westerlund <>
> * Lars Eggert <>
> Transport Area Advisor:
> * Lars Eggert <>
> Mailing Lists:
> General Discussion:
> To Subscribe:
> In Body: (un)subscribe
> Archive:
> 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-01.txt
> No Requests for Comments
> --
> Stanislav Shalunov
> _______________________________________________
> p2pi mailing list
p2pi mailing list