<div><div dir="auto">A buffer in a router is sized once. RTT varies.</div></div><div dir="auto">So BDP varies. That’s as simple as that.</div><div dir="auto">So you just cannot be always at optimum because you don’t know what RTT you have at any time.</div><div dir="auto"><br></div><div dir="auto">Lola si not solving that. No protocol could BTW.</div><div dir="auto">BTW I don’t see  any formal proof about queue occupancy in the paper.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr">On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM) <<a href="mailto:roland.bless@kit.edu">roland.bless@kit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Luca,<br>
<br>
Am 27.11.18 um 12:01 schrieb Luca Muscariello:<br>
> A BDP is not a large buffer. I'm not unveiling a secret. <br>
<br>
That depends on speed and RTT (note that typically there are<br>
several flows with different RTTs sharing the same buffer).<br>
The essential point is not how much buffer capacity is available,<br>
but how much is actually used, because that adds queueing delay.<br>
<br>
> And it is just a rule of thumb to have an idea at which working point<br>
> the protocol is working.<br>
<br>
No, one can actually prove that this is the best size for<br>
loss-based CC with backoff factor of 0.5 (assuming a single flow).<br>
<br>
> In practice the protocol is usually working below or above that value.<br>
<br>
That depends on the protocol.<br>
<br>
> This is where AQM and ECN help also. So most of the time the protocol is<br>
> working at way <br>
> below 100% efficiency.<br>
<br>
> My point was that FQ_codel helps to get very close to the optimum w/o<br>
> adding useless queueing and latency.<br>
> With a single queue that's almost impossible. No, sorry. Just impossible.<br>
<br>
No, it's possible. Please read the TCP LoLa paper.<br>
<br>
Regards,<br>
 Roland<br>
</blockquote></div></div>