Date:   Tue, 29 Sep 2020 10:25:25 -0700
From:   Priyaranjan Jha <priyarjha@...gle.com>
To:     Robert Bengtsson-Ölund 
        <robert.bengtsson-olund@...inor.se>
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

 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

Powered by blists - more mailing lists