netdev - Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6be0e30c-e9ec-17ea-968b-6ec5a9559dac@gmail.com>
Date:   Mon, 24 Aug 2020 09:13:58 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Robert Bengtsson-Ölund 
        <robert.bengtsson-olund@...inor.se>, netdev@...r.kernel.org,
        Priyaranjan Jha <priyarjha@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>
Subject: Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2
 to 4.19.y



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>