Daniel Sterling <sterling.dan...@gmail.com> writes: > On Mon, Jul 6, 2020 at 10:09 AM Luca Muscariello <muscarie...@ieee.org> wrote: >> If BBR can fix that by having a unique model for all these cases that would >> make deprecation, as intended in the paper, >> likely to happen. > > Interesting! Thank you all for helping a layperson like me understand. > > Obviously getting CC / latency control "correct" under wifi is a > difficult problem. > > I am wondering if you (the experts) have confidence we can solve it -- > that is, can end-users eventually see low latency by default with > standard gear? > > Or are shared transmission mediums like wifi doomed to require large > buffers for throughput, which means low latency can't be something we > can have "out of the box" -- ? Is sacrificing throughput for latency > required for "always low" latency on wifi?
To a certain extent, yes. However, this is orthogonal to the congestion control being used: WiFi gets its high throughput due to large aggregates (i.e., 802.11ac significantly increases the maximum allowed aggregation size compared to 802.11n). Because there's a fixed overhead for each transmission, the only way you can achieve the maximum theoretical throughput is by filling the aggregates, and if you do that while there are a lot of users contending for the medium, you will end up hurting latency. So really, the right thing to do in a busy network is to lower the maximum aggregate size: if you have 20 stations waiting to transmit and each only transmits for 1ms each instead of the maximum 4ms, you only add 20ms of delay while waiting for the other stations, instead of 80ms (best-case, not counting any backoff from collisions, queueing delay, etc). -Toke _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat