<div dir="ltr">A BDP is not a large buffer. I'm not unveiling a secret. <div>And it is just a rule of thumb to have an idea at which working point the protocol is working.</div><div>In practice the protocol is usually working below or above that value.</div><div>This is where AQM and ECN help also. So most of the time the protocol is working at way </div><div>below 100% efficiency.</div><div><br></div><div>My point was that FQ_codel helps to get very close to the optimum w/o adding useless queueing and latency.</div><div>With a single queue that's almost impossible. No, sorry. Just impossible.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 11:50 AM Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 27 Nov 2018, Luca Muscariello wrote:<br>
<br>
> link fully utilized is defined as Q>0 unless you don't include the <br>
> packet currently being transmitted. I do, so the TXtteer is never idle. <br>
> But that's a detail.<br>
<br>
As someone who works with moving packets, it's perplexing to me to <br>
interact with transport peeps who seem enormously focused on "goodput". My <br>
personal opinion is that most people would be better off with 80% of their <br>
available bandwidth being in use without any noticable buffer induced <br>
delay, as opposed to the transport protocol doing its damndest to fill up <br>
the link to 100% and sometimes failing and inducing delay instead.<br>
<br>
Could someone perhaps comment on the thinking in the transport protocol <br>
design "crowd" when it comes to this?<br>
<br>
-- <br>
Mikael Abrahamsson    email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>
</blockquote></div>