[Bloat] "BBR" TCP patches submitted to linux kernel

[Aaron Wood]

On Thu, Sep 29, 2016 at 8:50 PM, Dave Täht <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20160929/7d4a5f26/attachment-0002.html>