<div dir="ltr">The argument is absolutely correct for Reno, CUBIC and all other self-clocked protocols. One of the core assumptions in Jacobson88, was that the clock for the entire system comes from packets draining through the bottleneck queue. In this world, the clock is intrinsically brittle if the buffers are too small. The drain time needs to be a substantial fraction of the RTT.<div><br></div><div>However, we have reached the point where we need to discard that requirement. One of the side points of BBR is that in many environments it is cheaper to burn serving CPU to pace into short queue networks than it is to "right size" the network queues.</div><div><br></div><div>The fundamental problem with the old way is that in some contexts the buffer memory has to beat Moore's law, because to maintain constant drain time the memory size and BW both have to scale with the link (laser) BW.</div><div><br></div><div>See the slides I gave at the Stanford Buffer Sizing workshop december 2019: <a href="https://docs.google.com/presentation/d/1VyBlYQJqWvPuGnQpxW4S46asHMmiA-OeMbewxo_r3Cc/edit#slide=id.g791555f04c_0_5">Buffer Sizing: Position Paper</a> </div><div><br></div><div>Note that we are talking about DC and Internet core. At the edge, BW is low enough where memory is relatively cheap. In some sense BB came about because memory is too cheap in these environments.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Thanks,</div>--MM--<br>The best way to predict the future is to create it. - Alan Kay<br><br>We must not tolerate intolerance;</div><div dir="ltr"> however our response must be carefully measured: </div><div> too strong would be hypocritical and risks spiraling out of control;</div><div> too weak risks being mistaken for tacit approval.</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2 Jul 2021 09:42:24 -0700<br>
Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
<br>
> "Debunking Bechtolsheim credibly would get a lot of attention to the<br>
> bufferbloat cause, I suspect." - dpreed<br>
> <br>
> "Why Big Data Needs Big Buffer Switches" -<br>
> <a href="http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf" rel="noreferrer" target="_blank">http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf</a><br>
> <br>
<br>
Also, a lot depends on the TCP congestion control algorithm being used.<br>
They are using NewReno which only researchers use in real life.<br>
<br>
Even TCP Cubic has gone through several revisions. In my experience, the<br>
NS-2 models don't correlate well to real world behavior.<br>
<br>
In real world tests, TCP Cubic will consume any buffer it sees at a<br>
congested link. Maybe that is what they mean by capture effect.<br>
<br>
There is also a weird oscillation effect with multiple streams, where one<br>
flow will take the buffer, then see a packet loss and back off, the<br>
other flow will take over the buffer until it sees loss.<br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div>