I am not keeping up with iccrg as well as I could, but IMHO, loss, marking and delay can often be correlated. I did recently start up a bit of testing of BBRv2 over starlink over on the starlink mailing list.
On Tue, Mar 28, 2023 at 2:36 AM Ayush Mishra <ayumishra...@gmail.com> 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." > > BBRv1 essentially tried to deal with this problem by doing away with packet > loss as a congestion signal and having an entirely different philosophy to > congestion control. However, if we set aside the issue of buffer bloat, I > would imagine packet loss is a bad congestion signal in this situation > because most loss-based congestion control algorithms use it as a binary > signal with a binary response (back-off or no back-off). In other words, I > feel the blame must be placed on not just the congestion signal, but also on > how most algorithms respond to this congestion signal. > > On a per-packet basis, packet loss is a binary signal. But over a window, the > loss percentage and distribution, for example, can be a rich signal. There is > probably scope for differentiating between different kinds of packet losses > (and deciding how to react to them) when packet loss is coupled with the most > recent delay measurement too. Now that BBRv2 reacts to packet loss, are you > making any of these considerations too? > > This is not something I plan to present in iccrg tomorrow, just something I > was curious about :) > > Warmest regards, > Ayush > > On Fri, Aug 26, 2022 at 9:36 PM 'Neal Cardwell' via BBR Development > <bbr-...@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+unsubscr...@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. -- AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht Dave Täht CEO, TekLibre, LLC _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
