Re: [p2pi] [tana] TANA proposed charter

<toby.moncaster@bt.com> Thu, 23 October 2008 09:59 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 9133B3A6959; Thu, 23 Oct 2008 02:59:34 -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 76B9D3A6870; Thu, 23 Oct 2008 02:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.231
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9vSfqdD+pe0; Thu, 23 Oct 2008 02:59:25 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E77F73A6959; Thu, 23 Oct 2008 02:59:24 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com 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: <AEDCAF87EEC94F49BA92EBDD49854CC707EAA1CC@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] [tana] TANA proposed charter
Thread-Index: Ack0Zb6SCDlyQ/JWR2e2GDvAyNAPZgAjrBRw
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> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com>
From: <toby.moncaster@bt.com>
To: <shalunov@shlang.com>, <p2pi@ietf.org>, <tana@ietf.org>, <tsv-area@ietf.org>
X-OriginalArrivalTime: 23 Oct 2008 09:57:16.0932 (UTC) FILETIME=[BB369C40:01C934F5]
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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

Toby

____________________________________________________________________
Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 


> -----Original Message-----
> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf
Of
> Stanislav Shalunov
> Sent: 22 October 2008 17:46
> To: p2pi@ietf.org; tana@ietf.org; tsv-area@ietf.org 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):
> 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.
> 

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