<div><div dir="auto">I have never said that you need to fill the buffer to the max size to get full capacity, which is an absurdity.</div></div><div dir="auto"><br></div><div dir="auto">I said you need at least the BDP so that the queue never empties out.</div><div dir="auto">The link is fully utilized IFF the queue is never emptied.</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 11:26, 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 10:24 schrieb Luca Muscariello:<br>
> A congestion controlled protocol such as TCP or others, including QUIC,<br>
> LEDBAT and so on<br>
> need at least the BDP in the transmission queue to get full link<br>
> efficiency, i.e. the queue never empties out.<br>
<br>
This is not true. There are congestion control algorithms<br>
(e.g., TCP LoLa [1] or BBRv2) that can fully utilize the bottleneck link<br>
capacity without filling the buffer to its maximum capacity. The BDP<br>
rule of thumb basically stems from the older loss-based congestion<br>
control variants that profit from the standing queue that they built<br>
over time when they detect a loss:<br>
while they back-off and stop sending, the queue keeps the bottleneck<br>
output busy and you'll not see underutilization of the link. Moreover,<br>
once you get good loss de-synchronization, the buffer size requirement<br>
for multiple long-lived flows decreases.<br>
<br>
> This gives rule of thumbs to size buffers which is also very practical<br>
> and thanks to flow isolation becomes very accurate.<br>
<br>
The positive effect of buffers is merely their role to absorb<br>
short-term bursts (i.e., mismatch in arrival and departure rates)<br>
instead of dropping packets. One does not need a big buffer to<br>
fully utilize a link (with perfect knowledge you can keep the link<br>
saturated even without a single packet waiting in the buffer).<br>
Furthermore, large buffers (e.g., using the BDP rule of thumb)<br>
are not useful/practical anymore at very high speed such as 100 Gbit/s:<br>
memory is also quite costly at such high speeds...<br>
<br>
Regards,<br>
 Roland<br>
<br>
[1] M. Hock, F. Neumeister, M. Zitterbart, R. Bless.<br>
TCP LoLa: Congestion Control for Low Latencies and High Throughput.<br>
Local Computer Networks (LCN), 2017 IEEE 42nd Conference on, pp.<br>
215-218, Singapore, Singapore, October 2017<br>
<a href="http://doc.tm.kit.edu/2017-LCN-lola-paper-authors-copy.pdf" rel="noreferrer" target="_blank">http://doc.tm.kit.edu/2017-LCN-lola-paper-authors-copy.pdf</a><br>
<br>
> Which is: <br>
> <br>
> 1) find a way to keep the number of backlogged flows at a reasonable value. <br>
> This largely depends on the minimum fair rate an application may need in<br>
> the long term.<br>
> We discussed a little bit of available mechanisms to achieve that in the<br>
> literature.<br>
> <br>
> 2) fix the largest RTT you want to serve at full utilization and size<br>
> the buffer using BDP * N_backlogged.  <br>
> Or the other way round: check how much memory you can use <br>
> in the router/line card/device and for a fixed N, compute the largest<br>
> RTT you can serve at full utilization. <br>
> <br>
> 3) there is still some memory to dimension for sparse flows in addition<br>
> to that, but this is not based on BDP. <br>
> It is just enough to compute the total utilization of sparse flows and<br>
> use the same simple model Toke has used <br>
> to compute the (de)prioritization probability.<br>
> <br>
> This procedure would allow to size FQ_codel but also SFQ.<br>
> It would be interesting to compare the two under this buffer sizing. <br>
> It would also be interesting to compare another mechanism that we have<br>
> mentioned during the defense<br>
> which is AFD + a sparse flow queue. Which is, BTW, already available in<br>
> Cisco nexus switches for data centres.<br>
> <br>
> I think that the the codel part would still provide the ECN feature,<br>
> that all the others cannot have.<br>
> However the others, the last one especially can be implemented in<br>
> silicon with reasonable cost.<br>
</blockquote></div></div>