Re: [p2pi] [tana] TANA proposed charter

Stanislav Shalunov <shalunov@shlang.com> Wed, 22 October 2008 16:44 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7ADC28C148; Wed, 22 Oct 2008 09:44:43 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978C13A69BA for <p2pi@core3.amsl.com>; Wed, 22 Oct 2008 09:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dflNwdnrz3Vm for <p2pi@core3.amsl.com>; Wed, 22 Oct 2008 09:44:40 -0700 (PDT)
Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by core3.amsl.com (Postfix) with ESMTP id 4B0173A68AC for <p2pi@ietf.org>; Wed, 22 Oct 2008 09:44:40 -0700 (PDT)
Received: by qb-out-0506.google.com with SMTP id f17so3916523qba.41 for <p2pi@ietf.org>; Wed, 22 Oct 2008 09:45:56 -0700 (PDT)
Received: by 10.114.56.1 with SMTP id e1mr7776864waa.69.1224693955707; Wed, 22 Oct 2008 09:45:55 -0700 (PDT)
Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 4sm12266722yxd.2.2008.10.22.09.45.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 09:45:55 -0700 (PDT)
Message-Id: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com>
From: Stanislav Shalunov <shalunov@shlang.com>
To: p2pi@ietf.org, tana@ietf.org, "tsv-area@ietf.org Area" <tsv-area@ietf.org>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC707E291F2@E03MVZ1-UKDY.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 09:45:52 -0700
References: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com><B5A5E01F9387F4409E67604C0257C71E660E5F@NDJSEVS25A.ndc.nasa.gov> <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <AEDCAF87EEC94F49BA92EBDD49854CC707E291F2@E03MVZ1-UKDY.domain1.systemhost.net>
X-Mailer: Apple Mail (2.929.2)
Subject: Re: [p2pi] [tana] TANA proposed charter
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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 <magnus.westerlund@ericsson.com>
* Lars Eggert <lars.eggert@nokia.com>

Transport Area Advisor:
* Lars Eggert <lars.eggert@nokia.com>

Mailing Lists:

General Discussion: tana@ietf.org
To Subscribe: tana-request@ietf.org
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.

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.

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
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi