Message-ID: <CAM7CaVRUfix0-wfh8Z8SLOwxUSgDAzoFQPivq4iBi3j7kTaqXg@mail.gmail.com>
Date:   Wed, 30 Sep 2020 10:49:44 +0200
From:   Robert Bengtsson-Ölund 
        <robert.bengtsson-olund@...inor.se>
To:     Priyaranjan Jha <priyarjha@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
        Neal Cardwell <ncardwell@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>
Subject: Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2
 to 4.19.y

Thanks.
/Robert

On Tue, 29 Sep 2020 at 19:25, Priyaranjan Jha <priyarjha@...gle.com> wrote:
>
>  The BBR ACK aggregation patches have been packported to 4.19 kernel,
> and are part of v4.19.148 stable release:
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.19.148
>
> Thanks,
> Priyaranjan
>
>
> On Tue, Aug 25, 2020 at 2:02 AM Robert Bengtsson-Ölund
> <robert.bengtsson-olund@...inor.se> wrote:
> >
> > Much appreciated.
> >
> > Thank you everyone.
> > /Robert
> >
> >
> > On Mon, 24 Aug 2020 at 20:39, Priyaranjan Jha <priyarjha@...gle.com> wrote:
> > >
> > > Thank you, Eric, Robert.
> > > We will try to provide the backport for the patch soon.
> > >
> > > Thanks,
> > > Priyaranjan
> > >
> > > (resending since previous reply bounced back)
> > > On Mon, Aug 24, 2020 at 9:14 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
> > > >
> > > >
> > > >
> > > > On 8/24/20 7:35 AM, Robert Bengtsson-Ölund wrote:
> > > > > Hi everyone
> > > > >
> > > > > We stumbled upon a TCP BBR throughput issue that the following change fixes.
> > > > > git: 78dc70ebaa38aa303274e333be6c98eef87619e2
> > > > >
> > > > > Our issue:
> > > > > We have a transmission that is application limited to 20Mbps on an
> > > > > ethernet connection that has ~1Gbps capacity.
> > > > > Without this change our transmission seems to settle at ~3.5Mbps.
> > > > >
> > > > > We have seen the issue on a slightly different network setup as well
> > > > > between two fiber internet connections.
> > > > >
> > > > > Due to what the mentioned commit changes we suspect some middlebox
> > > > > plays with the ACK frequency in both of our cases.
> > > > >
> > > > > Our transmission is basically an RTMP feed through ffmpeg to MistServer.
> > > > >
> > > > > Best regards
> > > > > /Robert
> > > > >
> > > >
> > > > Please always CC patch authors in this kind of requests.
> > > >
> > > > Thanks.
> > > >
> > > > Patch was :
> > > >
> > > > commit 78dc70ebaa38aa303274e333be6c98eef87619e2
> > > > Author: Priyaranjan Jha <priyarjha@...gle.com>
> > > > Date:   Wed Jan 23 12:04:54 2019 -0800
> > > >
> > > >     tcp_bbr: adapt cwnd based on ack aggregation estimation
> > > >
> > > >     Aggregation effects are extremely common with wifi, cellular, and cable
> > > >     modem link technologies, ACK decimation in middleboxes, and LRO and GRO
> > > >     in receiving hosts. The aggregation can happen in either direction,
> > > >     data or ACKs, but in either case the aggregation effect is visible
> > > >     to the sender in the ACK stream.
> > > >
> > > >     Previously BBR's sending was often limited by cwnd under severe ACK
> > > >     aggregation/decimation because BBR sized the cwnd at 2*BDP. If packets
> > > >     were acked in bursts after long delays (e.g. one ACK acking 5*BDP after
> > > >     5*RTT), BBR's sending was halted after sending 2*BDP over 2*RTT, leaving
> > > >     the bottleneck idle for potentially long periods. Note that loss-based
> > > >     congestion control does not have this issue because when facing
> > > >     aggregation it continues increasing cwnd after bursts of ACKs, growing
> > > >     cwnd until the buffer is full.
> > > >
> > > >     To achieve good throughput in the presence of aggregation effects, this
> > > >     algorithm allows the BBR sender to put extra data in flight to keep the
> > > >     bottleneck utilized during silences in the ACK stream that it has evidence
> > > >     to suggest were caused by aggregation.
> > > >
> > > >     A summary of the algorithm: when a burst of packets are acked by a
> > > >     stretched ACK or a burst of ACKs or both, BBR first estimates the expected
> > > >     amount of data that should have been acked, based on its estimated
> > > >     bandwidth. Then the surplus ("extra_acked") is recorded in a windowed-max
> > > >     filter to estimate the recent level of observed ACK aggregation. Then cwnd
> > > >     is increased by the ACK aggregation estimate. The larger cwnd avoids BBR
> > > >     being cwnd-limited in the face of ACK silences that recent history suggests
> > > >     were caused by aggregation. As a sanity check, the ACK aggregation degree
> > > >     is upper-bounded by the cwnd (at the time of measurement) and a global max
> > > >     of BW * 100ms. The algorithm is further described by the following
> > > >     presentation:
> > > >     https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
> > > >
> > > >     In our internal testing, we observed a significant increase in BBR
> > > >     throughput (measured using netperf), in a basic wifi setup.
> > > >     - Host1 (sender on ethernet) -> AP -> Host2 (receiver on wifi)
> > > >     - 2.4 GHz -> BBR before: ~73 Mbps; BBR after: ~102 Mbps; CUBIC: ~100 Mbps
> > > >     - 5.0 GHz -> BBR before: ~362 Mbps; BBR after: ~593 Mbps; CUBIC: ~601 Mbps
> > > >
> > > >     Also, this code is running globally on YouTube TCP connections and produced
> > > >     significant bandwidth increases for YouTube traffic.
> > > >
> > > >     This is based on Ian Swett's max_ack_height_ algorithm from the
> > > >     QUIC BBR implementation.
> > > >
> > > >     Signed-off-by: Priyaranjan Jha <priyarjha@...gle.com>
> > > >     Signed-off-by: Neal Cardwell <ncardwell@...gle.com>
> > > >     Signed-off-by: Yuchung Cheng <ycheng@...gle.com>
> > > >     Signed-off-by: David S. Miller <davem@...emloft.net>
> > > >
> >
> >
> >
> > --
> > Robert Bengtsson-Ölund, System Developer
> > Software Development
> > +46(0)90-349 39 00
> >
> > www.intinor.com
> >
> > -- INTINOR --
> > WE ARE DIREKT



-- 
Robert Bengtsson-Ölund, System Developer
Software Development
+46(0)90-349 39 00

www.intinor.com

-- INTINOR --
WE ARE DIREKT

Powered by blists - more mailing lists