Re: [p2pi] [tana] [tsv-area] TANA proposed charter

<toby.moncaster@bt.com> Wed, 22 October 2008 12:28 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 20CD83A6B78; Wed, 22 Oct 2008 05:28:59 -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 ADA833A6AAE; Wed, 22 Oct 2008 05:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 4TOWP2FVl2Da; Wed, 22 Oct 2008 05:28:56 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A08BC3A69B7; Wed, 22 Oct 2008 05:28:55 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 13:29:22 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Oct 2008 13:29:18 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC707E291F2@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tana] [tsv-area] TANA proposed charter
Thread-Index: AckzmS9catvy+WU6SoiHfPKGL3HW9QAiRdVg
References: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com><B5A5E01F9387F4409E67604C0257C71E660E5F@NDJSEVS25A.ndc.nasa.gov> <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com>
From: <toby.moncaster@bt.com>
To: <bdavie@cisco.com>, <Wesley.M.Eddy@nasa.gov>
X-OriginalArrivalTime: 22 Oct 2008 12:29:22.0176 (UTC) FILETIME=[CFDE9800:01C93441]
Cc: p2pi@ietf.org, tana@ietf.org, tsv-area@ietf.org
Subject: Re: [p2pi] [tana] [tsv-area] 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

I agree that this is a pretty good charter. Just a few comments in-line
(mainly supporting Bruce's earlier comments).


> -----Original Message-----
> From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On Behalf
Of
> Bruce Davie
> Sent: 21 October 2008 16:06
> To: Eddy, Wesley M. (GRC-RCN0)[VZ]
> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org
> Subject: Re: [tana] [tsv-area] TANA proposed charter
> 
>   I'll start by saying that I support the WG and think the new charter
> is pretty good. I have a few suggestions for small changes.
> 
> > 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 the bottleneck link.
> 
> Replace ECN with Active Queue Management (AQM)
> 

Agree. In fact even ECN fills the head of the queue if it runs on RED
algo...

> > This increases the
> > delay experienced by other applications.
> 
> It would be more accurate to say "In the absence of any form of
> isolation in the queues, this increases..."
> 

Agree

> > 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.
> 
> Since there isn't complete agreement on the ideal size of a buffer,
> just say:
> 
> "If the buffer size is one RTT, the delay doubles...."
> 

Or "If the buffer is set to one RTT as often recommended, the delay
doubles..."

> > 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.
> [snip]
> 
> > 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,
> 
> perhaps it would be more precise to say:
> "quickly yield to traffic sharing the same bottleneck queue that uses
> standard TCP congestion control"

And do we mind about how it reacts to any other congestion control? Do
we need to mention possible interactions with other delay-based CC's?

> 
> > * add little to the queueing delays induced by TCP traffic,
> > * operate well in today's typical networks with FIFO queueing
> > with drop-tail discipline,
> 
> suggest deleting "today's typical"
> 

Agree - not sure we can call anything typical and we don't want to limit
our scope too much.

> > * where available, use explicit congestion notification (ECN),
> > active queue management (AQM), and/or end-to-end
> > differentiated services (DiffServ).
> [snip]
> 
> 
> > (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.
> 
> 
> This is just a bit confusingly worded and could be interpreted very
> broadly. I would suggest:
> "(2) A document that discusses the
> tradeoffs surrounding the use of many concurrent transport
> connections to one peer and/or to different peers and recommends best
> practices for applications in this regard."
> 

More or less agree with Bruce but it would be nice to make it clearer
that we are talking about one or more connections: "(2) A document that
discusses the tradeoffs of using many concurrent transport connections
to one peer and/or to different peers compared to single transport
connections between peers and recommends best practices for applications
in this regard."

> Finally, I hate the name, because it is so completely undescriptive of
> the WG. I like all of Wesley's suggestions better, MILT probably being
> the best.

Yes the name is awful, but as with all such things we are already
getting used to the acronym TANA. However if we do decide to change the
name how about:

"Congestion-Optimisation for Large Transfers (COLT)"
"Transport for Impact Limited Large Transfers (TILTT)"

Toby

> 
> Bruce
> 
> 
> On Oct 21, 2008, at 10:12 AM, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> 
> > The charter, as written looks reasonable to me.  I just hate the
name
> > :).
> >
> > Even though you explained it before, "Advanced Network Applications"
> > still bothers me as it's completely unspecific.  Furthermore, I
think
> > that "Techniques" isn't well-scoped enough to limit the work
properly
> > as it seems to be focused on congestion control techniques, and not
> > NAT traversal techniques, search techniques, etc.
> >
> > The way that the problem statement was described, I think what's
> > really
> > meant is "bulk transfer applications that want to be a good neighbor
> > to
> > real-time or other applications".  I guess the challenge is that
this
> > doesn't produce a pronouncable acronym like TANA :).
> >
> > It should really be something like:
> > "Minimizing Impact of Large Transfers" (MILT)
> > "Concurrent Realtime And Bulk Applications" (CRABA)
> > "Fast Transfers Adding Minimal Latency" (FTAML)
> > "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) --
> > probably not a good one as it looks too much like "barfing" :)
> >
> > But if nobody else has a problem with the TANA name, I'll keep my
> > mouth
> > shut so we don't waste time and energy.  There are bigger fish to
> fry!
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: tsv-area-bounces@ietf.org
> >> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Stanislav Shalunov
> >> Sent: Tuesday, October 21, 2008 9:17 AM
> >> To: tana@ietf.org; p2pi@ietf.org; TSV Area
> >> Subject: [tsv-area] TANA proposed charter
> >>
> >> 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.
> >>
> >> 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 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.
> >>
> >> (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. 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, 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 <http://shlang.com/>
> >>
> >> Hacking Startups <http://feeds.feedburner.com/~r/shlang/~6/1>
> >>
> >>
> 
> _______________________________________________
> tana mailing list
> tana@ietf.org
> https://www.ietf.org/mailman/listinfo/tana
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi