[Bloat] abc congestion control on time varying wireless links

[Dave Taht]

On Wed, Dec 11, 2019 at 11:54 AM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Wed, Dec 11, 2019 at 11:19 AM Prateesh Goyal <g.pratish at gmail.com> wrote:
> >
> > Adding Hari, Mohammad
> >
> > On Wed, Dec 11, 2019 at 2:17 PM Dave Taht <dave.taht at gmail.com> wrote:
> >>
> >> https://arxiv.org/pdf/1905.03429.pdf
> >>
> >> the principal item of interest is section 3.1.2 where the accelerate
> >> and brake concepts and math are described.
>
> What we have now is a string of conflicts of interest over the values
> of the ecn bits, in part based
> on the characteristics of the underlying link technologies.
>
> The DC folk want a multibit more immediate signal, for which L4S is
> kind of targetted, (and SCE also
> applies). I haven't seen any data on how well dctcp or SCE -style can
> work on wildly RTT varying links as yet, although it's been pitched at
> the LTE direction, not at wifi.
>
> The abc concept hasn't been tried in a DC-like environment, and while
> it shows some good results for both the LTE and wifi simulations, was
> not compared against the fq_codel based solution currently in linux
> wifi, nor against the minstrel rate controller.
>
> I have plenty of data on how fq_codel + RFC3168 ecn currently works on
> wifi, I like to think it's pretty good, but it's still pretty slow to
> respond with just RFC3168 or drop.
>
> this is yet another one of those cases where unified sets of
> benchmarks would help.
>
> And then there's, like, the actual deployment on actual devices... I
> just did a string of benchmarks, tethered to my new moto 6e phone. You
> saturate the download, and nearly ALL other traffic (icmp and udp) in
> the upstream direction, gets starved out.
>
> I just did a string of benchmarks on my new LTE

(I'll post these at some point)

Kan Yan, Toke, and a multitude of others have committed AQL
(Airtime queue limits) for the QCA ath10k 802.11ac chip to
the linux kernel and it should be appearing in mainline
and in openwrt soon if it hasn't already. (It already worked on the
mt76, and I'm hoping we can make it work on the iwl devices, notably
the new ax ones)

https://lore.kernel.org/linux-wireless/20191119060610.76681-5-kyan@google.com/

Kan's data and post about it:

https://drive.google.com/corp/drive/folders/14OIuQEHOUiIoNrVnKprj6rBYFNZ0Coif

The raw trace, parsed data in csv format and plots can be found here:
https://drive.google.com/open?id=1Mg_wHu7elYAdkXz4u--42qGCVE1nrILV

All tests are done with 2 TCP download sessions that oversubscribed
the link bandwidth.

With AQL on, the mean sojourn time about ~20000us, matches the default
codel "target".

With AQL off, the mean sojourn time is less than 4us even the latency
is off the charts, just as we expected that fd_codel with mac80211
alone is not effective for drivers with deep firmware/hardware queues.

Kan followed up with some 10ms vs 20 codel target data

> Apologize for the late reply. Here is the test results with target set to 10ms.
> The trace for the sojourn time:
> https://drive.google.com/open?id=1MEy_wbKKdl22yF17hZaGzpv3uOz6orTi
>
> Flent test for 20 ms target time vs 10 ms target time:
> https://drive.google.com/open?id=1leIWe0-L0XE78eFvlmRJlNmYgbpoH8xZ

At which point a debate kicked off on the make-wifi-list about using
the 10ms target on wifi, particularly with multiple stations transmitting.

https://lists.bufferbloat.net/pipermail/make-wifi-fast/2019-December/002605.html

To me, the arrival of AQL, and the applicability various AQM
technologies to 802.11ac devices is kind of a whole new debate, that
we simply do not have enough data on.


> >>
> >> --
> >> Make Music, Not War
> >>
> >> Dave Täht
> >> CTO, TekLibre, LLC
> >> http://www.teklibre.com
> >> Tel: 1-831-435-0729
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729