<html><head></head><body>Codel and PIE are excellent first steps... but I don't think they are the best eventual approach. I want to see them deployed ASAP in CMTS' s and server load balancing networks... it would be a disaster to not deploy the far better option we have today immediately at the point of most leverage. The best is the enemy of the good.<br>
<br>
But, the community needs to learn once and for all that throughput and latency do not trade off. We can in principle get far better latency while maintaining high throughput.... and we need to start thinking about that. That means that the framing of the issue as AQM is counterproductive. <br><br><div class="gmail_quote">On May 26, 2014, Mikael Abrahamsson <swmike@swm.pp.se> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k10mail">On Mon, 26 May 2014, dpreed@reed.com wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I would look to queue minimization rather than "queue management" (which <br />implied queues are often long) as a goal, and think harder about the <br />end-to-end problem of minimizing total end-to-end queueing delay while <br />maximizing throughput.</blockquote><br />As far as I can tell, this is exactly what CODEL and PIE tries to do. They <br />try to find a decent tradeoff between having queues to make sure the pipe <br />is filled, and not making these queues big enough to seriously affect <br />interactive performance.<br /><br />The latter part looks like what LEDBAT does?<br /><<a href="http://tools.ietf.org/html/rfc6817">http://tools.ietf.org/html/rfc6817</a>><br /><br />Or are you thinking about something else?<br /></pre></blockquote></div><br/>-- Sent from my Andro
id
device with <b><a href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@ Mail</a></b>. Please excuse my brevity.</body></html>