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