From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 56F543B25E for ; Fri, 30 Sep 2016 00:29:37 -0400 (EDT) Received: by mail-ua0-x233.google.com with SMTP id l16so65662517uaa.1 for ; Thu, 29 Sep 2016 21:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JHVTeOlpejlF/KdvfGngbrmC4WLFBd5q0IIjtsrabgk=; b=pRtZk5adRv7JEG/gcLi6HsWbw3G1XQid0/E1z5hj/Dbg3n7G+9PU7Zq+SYRpe+7rji UujYRF3dLVx6Yo1NHDhBKi1rG0NgJMmr5E/BEaRyl7JNSXdMfSTqs/BwsWriQZEvc9HO 9l4mqFLdhTF2P7txaxZGSeeTSSCBMm2dbEyKTHv/PWYTjOHyQmAhiA5TnePjagCgWkwZ mwFhQFgvPDKLetSbHZjy9VCeGKCi/Y5E8A3ueClxkrBEWW3983KhhKn00Jp4+4B+bJ4U C+mn885blghQPTzRkT4weyxTib589gCn9dhDnmnljs3cBvPoFMygWrfg+WXVnukUdnSr 7NeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JHVTeOlpejlF/KdvfGngbrmC4WLFBd5q0IIjtsrabgk=; b=TXNxmn9kmhMU2m8neeEFM3fCrcI4zLUs5g7CN1ExH1j7aK8KsUbo0kB/pgBZPqt90X 61Ht7qM0P2NDjLtn+Mo1ak2oxraoK0khHbEXC9xmYMLuXCqAx4U25OTMifUmIsKh0uuS JKdISloN1RaE3wWooYOS9izbyU9d55QPSPHKZqkwmccHb1i42DG9vymZ6J/mwAiM93Qn hVBMUN0AZep5ctPXhgs3UZxKnFcecd4pkEJTykAGTIHkz74dyLSLICDJq0iNr+6Te5W6 oLaz8MOOgHQ6Eh04pWoyF4GJvs2VpuIenjhNx9uIyHzAVo9jHdHT8WK9Duekm9NI9g3Q vTBg== X-Gm-Message-State: AA6/9Rlt7dRqqGfLq9VXcGtcdc4Oy0/swCXX3i5A+5icRxHm8MA0tv0bODQoLnUuOULOFuKNDX5FoEkRYu3+/A== X-Received: by 10.176.84.72 with SMTP id o8mr4013085uaa.128.1475209776427; Thu, 29 Sep 2016 21:29:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.117.214 with HTTP; Thu, 29 Sep 2016 21:29:35 -0700 (PDT) In-Reply-To: <1525bb51-cd92-2656-d48f-bb3a1a659569@taht.net> References: <20160916211120.GA38308@sesse.net> <1525bb51-cd92-2656-d48f-bb3a1a659569@taht.net> From: Aaron Wood Date: Thu, 29 Sep 2016 21:29:35 -0700 Message-ID: To: =?UTF-8?Q?Dave_T=C3=A4ht?= Cc: Mario Ferreira , bloat Content-Type: multipart/alternative; boundary=94eb2c1b0972b17b7b053db20a24 Subject: Re: [Bloat] "BBR" TCP patches submitted to linux kernel X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 04:29:37 -0000 --94eb2c1b0972b17b7b053db20a24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 29, 2016 at 8:50 PM, Dave T=C3=A4ht 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 --94eb2c1b0972b17b7b053db20a24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 29, 2016 at 8:50 PM, Dave T=C3=A4ht <<= a href=3D"mailto:dave@taht.net" target=3D"_blank">dave@taht.net> wrote:

>=C2=A0 =C2=A0 =C2=A0Android is still shipping linux 3.10? How... quaint= .
>
> Since this is mobile, I'm pretty sure it will present a wh= ole 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... =C2=A0woul= dn't BBR mitigate the local radio fw buffering?=C2=A0 The early rtt pro= bing should (hopefully) see an un-bloated link, and then tune off of that?= =C2=A0 So any local buffering would look like any other network path buffer= s.=C2=A0 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 var= ying lines-of-sight to the tower (say walking into a building, driving into= a tunnel or just past a parking garage...).

-Aaro= n=C2=A0
--94eb2c1b0972b17b7b053db20a24--