Message-ID: <CAM7CaVSCNO1MWNfzQhVwU0=hP_LYP9k1fzxyWTUfn2c9M-c8Ng@mail.gmail.com>
Date:   Tue, 25 Aug 2020 11:01:52 +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

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