<br>We have submitted a new draft to the LEDBAT WG and are planning to make a short presentation at the LEDBAT WG and the ICCRG. <br>We are looking forward to all your comments. <br><a href="http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00" target="_blank">http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00</a><br>

<br>The
basic idea is to have an architecture framework, to enable the
standardization of the various mechanisms of a network friendly congestion control such as
available bandwidth estimation, flow control and congestion detection
separately. This could result in pluggable components that could be
used in the overall congestion control protocol/s. Though the draft is intended for the LEDBAT WG, it could easily be extended to congestion control protocols in general. <br>
<br>Abstract:<br><pre>   The Low Extra Delay Background Transport (LEDBAT) working group is<br>   considering protocols for an alternative congestion control protocol<br>   that enables a delay-insensitive networking application to minimize<br>
   the extra queueing delay it causes to other applications because of<br>   additional queueing at the bottleneck, when these connections<br>   carrying traffic for such applications attempt to use the available<br>   bandwidth.<br>
<br><br>   This document proposes an architectural framework for LEDBAT<br>   congestion control mechanisms, based on existing work on congestion<br>   control protocols and the requirements of the LEDBAT working group.<br>
   The architectural framework consists of a LEDBAT-congestion control<br>   (LEDBAT-CC) suite that provides flexibility in utilizing different<br>   components for providing congestion control for transport connections<br>
   carrying delay-insensitive traffic.  The LEDBAT-CC suite of protocols<br>   is envisioned to support the multiple alternative mechanisms for<br>   bandwidth estimation, congestion detection and indication and end-<br>   system flow control to comprise a network friendly congestion<br>
   avoidance protocol.<br><br><br>   This document is inspired by the need to standardize the various<br>   components that constitute the network friendly congestion control<br>   protocol to avoid having to individually standardize a multitude of<br>
   distinct and monolithic solutions.<br></pre> <br>Feedback is welcome, <br>Mayutan Arumaithurai