<font face="arial" size="2"><p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">On Monday, May 26, 2014 9:02am, "Mikael Abrahamsson" <swmike@swm.pp.se> said:<br /><br /></p>
<div id="SafeStyles1401112405">
<p style="margin:0;padding:0;">> So, I'd agree that a lot of the time you need very little buffers, but<br />> stating you need a buffer of 2 packets deep regardless of speed, well, I<br />> don't see how that would work.<br />></p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">My main point is that looking to increased buffering to achieve throughput while maintaining latency is not that helpful, and often causes more harm than good. There are alternatives to buffering that can be managed more dynamically (managing bunching and something I didn't mention - spreading flows or packets within flows across multiple routes when a bottleneck appears - are some of them).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I would look to queue minimization rather than "queue management" (which implied queues are often long) as a goal, and think harder about the end-to-end problem of minimizing total end-to-end queueing delay while maximizing throughput.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">It's clearly a totally false tradeoff between throughput and latency - in the IP framework.  There is no such tradeoff for the operating point.  There may be such a tradeoff for certain specific implementations of TCP, but that's not fixed in stone.</p>
<p style="margin:0;padding:0;"> </p>
</div></font>