<div dir="ltr">OK. We agree.<div>That's correct, you need *at least* the BDP in flight so that the bottleneck queue never empties out.</div><div><br></div><div>This can be easily proven using fluid models for any congestion controlled source no matter if it is </div><div>loss-based, delay-based, rate-based, formula-based etc.</div><div><br></div><div>A highly paced source gives you the ability to get as close as theoretically possible to the BDP+epsilon</div><div>as possible.</div><div><br></div><div>link fully utilized is defined as Q>0 unless you don't include the packet currently being transmitted. I do,</div><div>so the TXtteer is never idle. But that's a detail.</div><div><br></div><div><br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 11:35 AM 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,<br>
<br>
Am 27.11.18 um 11:29 schrieb Luca Muscariello:<br>
> I have never said that you need to fill the buffer to the max size to<br>
> get full capacity, which is an absurdity.<br>
<br>
Yes, it's absurd, but that's what today's loss-based CC algorithms do.<br>
<br>
> I said you need at least the BDP so that the queue never empties out.<br>
> The link is fully utilized IFF the queue is never emptied.<br>
<br>
I was also a bit imprecise: you'll need a BDP in flight, but<br>
you don't need to fill the buffer at all. The latter sentence<br>
is valid only in the direction: queue not empty -> link fully utilized.<br>
<br>
Regards,<br>
Roland<br>
<br>
> <br>
> <br>
> <br>
> On Tue 27 Nov 2018 at 11:26, Bless, Roland (TM) <<a href="mailto:roland.bless@kit.edu" target="_blank">roland.bless@kit.edu</a><br>
> <mailto:<a href="mailto:roland.bless@kit.edu" target="_blank">roland.bless@kit.edu</a>>> wrote:<br>
> <br>
> 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<br>
> 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<br>
> reasonable value. <br>
> > This largely depends on the minimum fair rate an application may<br>
> need in<br>
> > the long term.<br>
> > We discussed a little bit of available mechanisms to achieve that<br>
> 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<br>
> 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<br>
> 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>
> <br>
<br>
</blockquote></div></div></div></div>