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

[Neal Cardwell <ncardwell@google.com>]

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

Hi Bob,

Good question. I can imagine a number of different techniques to generate
and measure the traffic flows for this kind of study, and don't have any
particular suggestions.

neal


On Fri, Aug 26, 2022 at 4:54 PM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> Hi Neal,
>
> Any thoughts on tooling to generate and measure the traffic flows BBR is
> designed to optimize? I've been adding some low duty cycle support in iperf
> 2 <https://sourceforge.net/projects/iperf2/> with things like --bounceback
> and --burst-period and --burst-period
> <https://iperf2.sourceforge.io/iperf-manpage.html>. We could pull the
> size and period from a known distribution or distributions though not sure
> what to pick.
>
> Thanks,
> Bob
>
> Bob
>
> On Fri, Aug 26, 2022 at 6:36 AM 'Neal Cardwell' via BBR Development <
> bbr-dev@googlegroups.com> wrote:
>
>> 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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "BBR Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bbr-dev+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1%3DaoTTQE2263o8HF9ye_TQg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1%3DaoTTQE2263o8HF9ye_TQg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.

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