Subject: [tsv-area] Techniques for Advanced Networking Applications (TANA) BoF, IETF-72, Dublin

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 14 Jul 2008 16:48:35 -0700

I would bring your attention to the TANA BoF (http://www3.tools.ietf.org/agenda/72/tana.html 
).  It is scheduled for Thursday, July 31, 2008 at 3PM in Dublin.

I'm attaching the BoF summary.  The problem statement can be found at http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt

We're looking for BoF participants, possibly another speaker, and also  
document authors, reviewers, and generally interested parties.  If  
you're interested, please speak up!

[email-masked] is the best mailing list for discussion.  We're  
looking for feedback on the problem statement and the summary.

Thank you,

-- 
Stanislav Shalunov
http://shlang.com

Techniques for Advanced Networking Applications (TANA) BoF
*** Draft - please send additions/corrections to WG Chairs ***
IETF-72, Dublin, Ireland

WG Chairs: Stanislav Shalunov <[email-masked]>
            Gorry Fairhurst <[email-masked]>
Jabber:
Note-taker at IETF-72: To be determined

1. Agenda Bashing (5 mins)

2. Short Presentations (80 minutes including questions)

* TANA Problem Statement - Stanislav Shalunov (10 minutes)
http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt

* Uses of end-to-end Scavenger Service - Marshall Ewbanks (10 minutes)

* P2P Application Requirements for TANA - Laird Popkin (10 minutes)

* - Speaker 4 tbd (10 minutes)

3. Discussion of Way Forward (30 minutes)

4. Summary of Current Position (2 minutes)

-----------------------------------------------------------------

Summary of BoF

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
often 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
other interactive applications. VoIP and games are particularly
affected, but even web browsing may become problematic.

TANA is a transport-area BoF 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 BoF will explore the following potential work items:

(1) A 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. Among the desired features of such an algorithm are
the ability to maintain short standing queues, the capability
to quickly yield to regular best-effort traffic that uses
standard congestion control, the ability to utilize explicit
congestion notification (ECN), active queue management (AQM),
and/or end-to-end differentiated services (DiffServ) where
available, as well as effective operation in today's typical
situations where some or all of these mechanisms are not
available. In addition to specifying a congestion control
algorithm, the work may also include specifications of how such an
algorithm is to be used in specific UDP-based protocols.
(Application of the algorithm to other transport protocols 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 transport connections to
transfer through a bottleneck, it tends to experience a
larger fraction of the bottleneck's loaded resource than if it
had used fewer connections. Note that 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.

Last updated 8th July 2008/2

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 14 Jul 2008 17:12:58 -0700

We got Marshall's name wrong.  Correct name is Marshall Eubanks.   
Sorry, Marshall!

Will fix in the agenda.

On Jul 14, 2008, at 4:48 PM, Stanislav Shalunov wrote:

> I'm attaching the BoF summary.  The problem statement can be found  
> at http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
>
> We're looking for BoF participants, possibly another speaker, and  
> also document authors, reviewers, and generally interested parties.   
> If you're interested, please speak up!
>

-- 
Stanislav Shalunov
http://shlang.com

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 22 Jul 2008 14:19:48 -0700

The correct time for the TANA BoF is Thursday, July 31, 2008 at 1PM.   
I am also attaching an iCal event to this message.

Thank you and looking forward to seeing you at the BoF,
-- Stas

--
Stanislav Shalunov