<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 2, 2023 at 10:03 PM Neal Cardwell <<a href="mailto:ncardwell@google.com">ncardwell@google.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 2, 2023 at 8:14 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</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">Hi Ayush,<br>
<br>
> On Mar 28, 2023, at 11:36, Ayush Mishra via Bloat <<a href="mailto:bloat@lists.bufferbloat.net" target="_blank">bloat@lists.bufferbloat.net</a>> wrote:<br>
> <br>
> Hey Neal,<br>
> <br>
> I was revisiting this thread before presenting this paper in iccrg tomorrow - and I was particularly intrigued by one of the motivations you mentioned for BBR:<br>
> <br>
> "BBR is not trying to maintain a higher throughput than CUBIC in these kinds of scenarios with steady-state bulk flows. BBR is trying to be robust to the kinds of random packet loss that happen in the real world when there are flows dynamically entering/leaving a bottleneck."<br>
<br>
But isn't "when there are flows dynamically entering" actually a bona fide reason for the already established flows to scale back a bit, to give the new-commers some room to establish themselves?<br></blockquote><div><br></div><div>Yes, I agree that "when there are flows dynamically entering" is actually a bona fide reason for the already established flows to scale back to give the newcomers some room to establish themselves. I'm not arguing against scaling back to give the newcomers some room to establish themselves. I'm arguing against the specific way that Reno and CUBIC behave to try to accomplish that. :-)</div></div></div></blockquote><div>==> I agree too. But I think one of the key challenges here could be when the dynamically entering flows are extremely tiny (which I imagine is quite common). In those cases, there is a possibility that by the time the long-running flow backs off, the congestion it was responding to has already ended because the tiny flows have exited the bottleneck (think microbursts caused by flows that last 1-2 RTTs). In a perfect world we'd like to deal with elephant and mice flows in isolation at the switch, but there are likely things we can do from the endpoint too. Maybe some kind of a two-phase backoff, with the second phase only kicking in after a period of hysteresis to make sure it's responding to persistent congestion and not just brief microbursts. This is just off the top of my head, so I'm not sure how something like this would play out in the overall dynamics and convergence of the algorithm that implements it.</div></div></div>