[Iccrg] FW: [tana] HEADS UP: charter going for external review

Thu Oct 30 19:23:54 GMT 2008

FYI - ICCRG people are likely to have interest in this proposed charter
for a new IETF working group to address some of the issues with
congestion
control that p2p applications have encountered:

 

>-----Original Message-----
>From: tana-bounces at ietf.org [mailto:tana-bounces at ietf.org] On 
>Behalf Of Lars Eggert
>Sent: Thursday, October 30, 2008 3:06 PM
>To: tana at ietf.org
>Subject: [tana] HEADS UP: charter going for external review
>
>Hi,
>
>FYI, during the informal telechat today, the IESG has agreed to start  
>external review of the WG charter. You can find the charter text that  
>will be sent out by the secretariat for feedback below. (Stas, thanks  
>for incorporating the feedback from the list!) You'll see that we've  
>attempted to improve the WG name, too: "Low Extra Delay Background  
>Transport (LEDBAT) WG".
>
>The wider IETF community now gets one week to comment, and the IESG  
>will then decide whether or not to charter during the telechat next  
>Thursday. Please participate during the charter discussion on 
>the main  
>IETF list.
>
>Finally: I'm looking for additional candidates for a second co-chair.  
>If you are interested and have the cycles, please drop me a private  
>email that explains why you'd be a good choice. There is *no*  
>requirement for having prior IETF chairing experience.
>
>Lars
>
>---
>
>Low Extra Delay Background Transport (LEDBAT) WG
>[Note: The LEDBAT WG stems from the TANA BoF held in Dublin.]
>
>
>Chair(s):
>* Stanislav Shalunov <shalunov at shlang.com>
>* 2nd co-chair to be determined
>
>Transport Area Director(s):
>* Magnus Westerlund <magnus.westerlund at ericsson.com>
>* Lars Eggert <lars.eggert at nokia.com>
>
>Transport Area Advisor:
>* Lars Eggert <lars.eggert at nokia.com>
>
>
>Mailing Lists:
>
>General Discussion: tana at ietf.org
>To Subscribe: tana-request at ietf.org
>In Body: (un)subscribe
>Archive: http://www.ietf.org/mail-archive/web/tana/
>[Note: If chartered, mailing list will change to ledbat at ietf.org.]
>
>
>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
>
>
>_______________________________________________
>tana mailing list
>tana at ietf.org
>https://www.ietf.org/mailman/listinfo/tana
>