[p2pi] Fwd: WG Action: Low Extra Delay Background Transport (ledbat)

Stanislav Shalunov <shalunov@shlang.com> Thu, 13 November 2008 10:53 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0CA733A6868; Thu, 13 Nov 2008 02:53:05 -0800 (PST)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 388443A6868 for <p2pi@core3.amsl.com>; Thu, 13 Nov 2008 02:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7hksJ5bDfTig for <p2pi@core3.amsl.com>; Thu, 13 Nov 2008 02:53:02 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com []) by core3.amsl.com (Postfix) with ESMTP id 728973A6807 for <p2pi@ietf.org>; Thu, 13 Nov 2008 02:53:02 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so811770rvf.49 for <p2pi@ietf.org>; Thu, 13 Nov 2008 02:53:01 -0800 (PST)
Received: by with SMTP id r4mr5431374rve.242.1226573581843; Thu, 13 Nov 2008 02:53:01 -0800 (PST)
Received: from ? (c-67-188-243-194.hsd1.ca.comcast.net []) by mx.google.com with ESMTPS id k2sm31100171rvb.1.2008. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Nov 2008 02:53:01 -0800 (PST)
Message-Id: <51EB0268-A743-4D58-A268-0B8CFA56ECBD@shlang.com>
From: Stanislav Shalunov <shalunov@shlang.com>
To: p2pi@ietf.org, "tsv-area@ietf.org Area" <tsv-area@ietf.org>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 13 Nov 2008 02:52:58 -0800
References: <20081111183001.3D9CF28C18D@core3.amsl.com>
X-Mailer: Apple Mail (2.929.2)
Subject: [p2pi] Fwd: WG Action: Low Extra Delay Background Transport (ledbat)
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: multipart/mixed; boundary="===============1441628924=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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 ledbat@ietf.org.

Thank you,  -- Stas

Begin forwarded message:

> From: IESG Secretary <iesg-secretary@ietf.org>
> Date: November 11, 2008 10:30:01 AM PST
> To: ietf-announce@ietf.org
> Cc: shalunov@shlang.com, muraris@microsoft.com, ledbat@ietf.org
> 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 [shalunov@shlang.com]
> * Murari Sridhavan [muraris@microsoft.com]
> 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: ledbat@ietf.org
> 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

p2pi mailing list