Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

[Ayush Mishra <ayumishra.95@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

On Sun, Apr 2, 2023 at 10:03 PM Neal Cardwell <ncardwell@google.com> wrote:

>
>
> On Sun, Apr 2, 2023 at 8:14 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Ayush,
>>
>> > On Mar 28, 2023, at 11:36, Ayush Mishra via Bloat <
>> bloat@lists.bufferbloat.net> wrote:
>> >
>> > Hey Neal,
>> >
>> > 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:
>> >
>> > "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."
>>
>> 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?
>>
>
> 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. :-)
>
==> 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.

[-- Attachment #2: Type: text/html, Size: 3088 bytes --]