Subject: [tsv-area] Fwd: WG Action: Low Extra Delay Background Transport (ledbat)

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 13 Nov 2008 02:52:58 -0800

LEDBAT was formerly known as TANA.  If you were subscribed, your  
subscription should have been migrated.  If you were not and are  
interested, please consider subscribing to [email-masked].

Thank you,  -- Stas

Begin forwarded message:

> From: IESG Secretary <[email-masked]>
> Date: November 11, 2008 10:30:01 AM PST
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: WG Action: Low Extra Delay Background Transport (ledbat)
>
> A new IETF working group has been formed in the Transport Area.  For
> additional information, please contact the Area Directors or the WG
> Chairs.
>
> Low Extra Delay Background Transport (ledbat)
> --------------------------------------------------------------
> Current Status: Active Working Group
>
> Last Modified: 2008-11-06
>
> Chair(s):
> * Stanislav Shalunov [[email-masked]]
> * Murari Sridhavan [[email-masked]]
>
> Transport Area Director(s):
> * Magnus Westerlund [[email-masked]]
> * Lars Eggert [[email-masked]]
>
> Transport Area Advisor:
> * Lars Eggert [[email-masked]]
>
> Mailing Lists:
>
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat
> In Body: (un)subscribe
> Archive: http://www.ietf.org/mail-archive/web/ledbat/
>
> Description of Working Group:
>
> The LEDBAT 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.
>
> 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.
>
> LEDBAT 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
>
> * be deployable for popular applications that currently
> comprise noticeable fractions of Internet traffic
>
> * 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.
>
> Once experience is gained with this congestion control
> algorithm on the Internet, the WG will consider if it is
> appropriate to ask the IESG to advance the document as a
> Proposed Standard.
>
> (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.
>
> 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.
>
> Goals and Milestones:
>
> Oct 2009 Submit "Multiple Transport Connections in Applications  
> Design"
> to the IESG for consideration as an Informational RFC
>
> Oct 2009 Submit "Low Extra Delay Background Transport (LEDBAT)"
> to the IESG for consideration as an Experimental RFC

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 13 Nov 2008 03:20:22 -0800

P.S. The URL to subscribe is https://www.ietf.org/mailman/listinfo/ledbat

--
Stanislav Shalunov