> On 8 Jul, 2021, at 4:29 pm, Matt Mathis via Bloat > <bloat@lists.bufferbloat.net> wrote: > > That said, it is also true that multi-stream BBR behavior is quite > complicated and needs more queue space than single stream. This complicates > the story around the traditional workaround of using multiple streams to > compensate for Reno & CUBIC lameness at larger scales (ordinary scales > today). Multi-stream does not help BBR throughput and raises the queue > occupancy, to the detriment of other users.
I happen to think that using multiple streams for the sake of maximising throughput is the wrong approach - it is a workaround employed pragmatically by some applications, nothing more. If BBR can do just as well using a single flow, so much the better. Another approach to improving the throughput of a single flow is high-fidelity congestion control. The L4S approach to this, derived rather directly from DCTCP, is fundamentally flawed in that, not being fully backwards compatible with ECN, it cannot safely be deployed on the existing Internet. An alternative HFCC design using non-ambiguous signalling would be incrementally deployable (thus applicable to Internet scale) and naturally overlaid on existing window-based congestion control. It's possible to imagine such a flow reaching optimal cwnd by way of slow-start alone, then "cruising" there in a true equilibrium with congestion signals applied by the network. In fact, we've already shown this occurring under lab conditions; in other cases it still takes one CUBIC cycle to get there. BBR's periodic probing phases would not be required here. > IMHO, two approaches seem to be useful: > a) congestion-window-based operation with paced sending > b) rate-based/paced sending with limiting the amount of inflight data So this corresponds to approach a) in Roland's taxonomy. - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
