Re: [p2pi] TANA proposed charter
Marshall Eubanks <tme@multicasttech.com> Tue, 21 October 2008 20:12 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 1F46E3A6B97; Tue, 21 Oct 2008 13:12:32 -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 E09893A6A15; Tue, 21 Oct 2008 13:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.406
X-Spam-Level:
X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 nh3272aEtcfv; Tue, 21 Oct 2008 13:12:29 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 711FD3A6B52; Tue, 21 Oct 2008 13:12:29 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13467101; Tue, 21 Oct 2008 16:13:43 -0400
Message-Id: <DF480F89-FEBD-4BEE-97CA-AE0260466BA7@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: Stanislav Shalunov <shalunov@shlang.com>
In-Reply-To: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 16:13:41 -0400
References: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com>
X-Mailer: Apple Mail (2.929.2)
Cc: TSV Area <tsv-area@ietf.org>, tana@ietf.org, p2pi@ietf.org
Subject: Re: [p2pi] 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
I think that over all this is a decent charter and I support and hope to participate in this work. Some comments and nits follow. (I, by the way, have no trouble with the proposed name.) Regards Marshall On Oct 21, 2008, at 9:17 AM, Stanislav Shalunov wrote: > 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 <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. > Should this read "should saturate bottlenecks while retaining fairness" ? > 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 s/ECN/ECN, / > 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. Are there FEC issues here ? I see possibly a couple : - FEC may have fairness / congestion control issues in this context as it involves bandwidth usage that scales with the underlying application, and yet may be separately controlled. In general it is assumed that, say, a 30% FEC is "OK" if the underlying application uses congestion control, but if you are trying to saturate a bottleneck that may not be true if the FEC is added on top of the saturating flow. - in a scavenger service it might be very useful to have a mechanism to distinguish between control and other critical data, which might benefit from FEC, and the mass of the data, which might not need or warrant FEC. Some standardized means of signaling this might be useful. > > > (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. The above wording is not clear to me. Are you referring to TCP in the above sentence ? If so, be specific. > 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, s/The WG document/The WG will document/ > 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
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Reinaldo Penno
- Re: [p2pi] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tsv-area] TANA proposed charter Stanislav Shalunov
- [p2pi] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tsv-area] TANA proposed charter Lars Eggert
- Re: [p2pi] [tsv-area] TANA proposed charter Bruce Davie
- Re: [p2pi] [tsv-area] TANA proposed charter Joe Touch
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Marshall Eubanks
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Joe Touch
- Re: [p2pi] [tsv-area] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tsv-area] TANA proposed charter Salman Abdul Baset
- Re: [p2pi] [tsv-area] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tsv-area] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Lars Eggert
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- Re: [p2pi] TANA proposed charter Reinaldo Penno
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- Re: [p2pi] TANA proposed charter Marshall Eubanks
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tsv-area] TANA proposed charter Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [p2pi] [tsv-area] TANA proposed charter Murari Sridharan
- Re: [p2pi] [tsv-area] TANA proposed charter Ted Faber
- Re: [p2pi] [tsv-area] TANA proposed charter Ted Faber
- Re: [p2pi] [tsv-area] TANA proposed charter Caitlin Bestler
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Ted Faber
- Re: [p2pi] [tsv-area] TANA proposed charter Das, Saumitra
- Re: [p2pi] [tsv-area] [tana] TANA proposed charter Das, Saumitra
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Rolf Winter
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Laird Popkin
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Salvatore Loreto
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Reinaldo Penno
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Rolf Winter
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Reinaldo Penno
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Rolf Winter
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Kurt Tutschku
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter toby.moncaster
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tsv-area] TANA proposed charter Ingemar Johansson S
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Michael Menth
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Michael Welzl
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Roland Bless
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Roland Bless
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Nicholas Weaver
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Marshall Eubanks
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Marshall Eubanks
- Re: [p2pi] [tana] TANA proposed charter Stanislav Shalunov
- Re: [p2pi] [tana] TANA proposed charter Laird Popkin
- Re: [p2pi] [tana] TANA proposed charter Enrico Marocco
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Rolf Winter
- Re: [p2pi] [tana] TANA proposed charter toby.moncaster
- Re: [p2pi] [tsv-area] TANA proposed charter toby.moncaster
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter toby.moncaster
- Re: [p2pi] [tsv-area] TANA proposed charter Mark Allman
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Bryan Ford
- Re: [p2pi] [tana] TANA proposed charter Gorry Fairhurst
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Narayanan, Vidya
- [p2pi] TANA proposed charter -- packet marking qu… John Leslie
- Re: [p2pi] TANA proposed charter -- packet markin… Nicholas Weaver
- Re: [p2pi] TANA proposed charter -- packet markin… John Leslie
- Re: [p2pi] TANA proposed charter -- packet markin… Nicholas Weaver
- Re: [p2pi] TANA proposed charter Livingood, Jason
- Re: [p2pi] TANA proposed charter -- packet markin… Laird Popkin
- Re: [p2pi] [tana] TANA proposed charter -- packet… Woundy, Richard
- Re: [p2pi] TANA proposed charter -- packet markin… Stanislav Shalunov
- Re: [p2pi] TANA proposed charter -- packet markin… Robb Topolski
- Re: [p2pi] TANA proposed charter -- packet markin… Nicholas Weaver
- Re: [p2pi] TANA proposed charter -- packet markin… Bruce Davie
- Re: [p2pi] [tana] [tsv-area] TANA proposed charter Robb Topolski