Transport protocols and bulk file transfer

["Lawrence D. Dunn" <>]

I2 transport folks,
  I agreed to forward this on our call today, for those that haven't  
seen it.
  One more "results of BOF" note coming in a minute...

Larry
--


Begin forwarded message:

> From: Stanislav Shalunov 
> <>
> Date: July 14, 2008 6:48:35 PM CDT
> To: 
>
> Subject: [tsv-area] Techniques for Advanced Networking Applications  
> (TANA) BoF, IETF-72, Dublin
>
> 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!
>
>  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 
> <>
>           Gorry Fairhurst 
> <>
> 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