Thanks. /Robert On Tue, 29 Sep 2020 at 19:25, Priyaranjan Jha <priyar...@google.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-ol...@intinor.se> wrote: > > > > Much appreciated. > > > > Thank you everyone. > > /Robert > > > > > > On Mon, 24 Aug 2020 at 20:39, Priyaranjan Jha <priyar...@google.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.duma...@gmail.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 <priyar...@google.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 <priyar...@google.com> > > > > Signed-off-by: Neal Cardwell <ncardw...@google.com> > > > > Signed-off-by: Yuchung Cheng <ych...@google.com> > > > > Signed-off-by: David S. Miller <da...@davemloft.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
