On Thu, Sep 29, 2016 at 8:50 PM, Dave Täht <dave@taht.net> wrote:

> Android is still shipping linux 3.10? How... quaint.
>
> Since this is mobile, I'm pretty sure it will present a whole new host
> of "data points".

yes! (there have been a few studies of this, btw)

The part that we don't really know on the android handsets is how
much buffering there really is between qdisc, driver, and firmware,
which no doubt varies between models - and within a model on the
different wifi and 4G stacks. Odds are - just as we just ripped out on
the ath9k/ath10k - so much intermediate buffering exists as to make
applying the latency managing qdisc on top of marginal effectiveness.

In the case of BBR, well, there is some hope that would regulate
TCP on the uplink, but it will have no effect on the down (neither will
the qdiscs) - and it requires sch_fq to work properly - which
means that you'd have a choice between bbr + sch_fq, or
sch_cake/sch_fq_codel

yet... wouldn't BBR mitigate the local radio fw buffering? The early rtt probing should (hopefully) see an un-bloated link, and then tune off of that? So any local buffering would look like any other network path buffers. True, it doesn't help with downlink data, but it may with the uplink.

I'm not sure that you can use cake on mobile, not with the sorts of wildly changing bandwidths that I've been seeing (<5 to >50Mbps within a few seconds, as one moves through varying lines-of-sight to the tower (say walking into a building, driving into a tunnel or just past a parking garage...).

-Aaron