[Bloat] Are we heading towards a BBR-dominant Internet?

[Neal Cardwell]

Yes, I agree the assumptions are key here. One key aspect of this paper is
that it focuses on the steady-state behavior of bulk flows.

Once you allow for short flows (like web pages, RPCs, etc) to dynamically
enter and leave a bottleneck, the considerations become different. As is
well-known, Reno/CUBIC will starve themselves if new flows enter and cause
loss too frequently. For CUBIC, for a somewhat typical 30ms broadband path
with a flow fair share of 25 Mbit/sec, if new flows enter and cause loss
more frequently than roughly every 2 seconds then CUBIC will not be able to
utilize its fair share. For a high-speed WAN path, with 100ms RTT and fair
share of 10 Gbit/sec,  if new flows enter and cause loss more frequently
than roughly every 40 seconds then CUBIC will not be able to utilize its
fair share. Basically, loss-based CC can starve itself in some
very typical kinds of dynamic scenarios that happen in the real world.

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.

cheers,
neal




On Thu, Aug 25, 2022 at 8:01 PM Dave Taht via Bloat <
bloat at lists.bufferbloat.net> wrote:

> I rather enjoyed this one. I can't help but wonder what would happen
> if we plugged some different assumptions into their model.
>
> https://www.comp.nus.edu.sg/~bleong/publications/imc2022-nash.pdf
>
> --
> FQ World Domination pending:
> https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20220826/64d236ad/attachment.html>