lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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