patches in Linux TCP BBR for higher throughput with aggregation (wifi, etc.)

515 views
Skip to first unread message

Neal Cardwell

unread,
Mar 13, 2019, 1:46:34 AM3/13/19
to BBR Development

Hi,


We wanted to mention that patches are now in the Linux TCP BBR code for achieving higher throughput with network paths exhibiting significant aggregation effects (wifi, cable modems, etc.) As of recently the patches are in davem/net-next and now the master Linux tree from Linus, so those patches will be in Linux 5.1. We were originally waiting until Linux 5.1 is released to announce that on this e-mail list. But since it came up anyway today in another thread, we may as well mention it and provide a bit more context. ;-)


The specific patches are:

  232aa8ec3ed9 tcp_bbr: refactor bbr_target_cwnd() for general inflight provisioning
  78dc70ebaa38 tcp_bbr: adapt cwnd based on ack aggregation estimation

This patch series was originally sent in April 2018:
This came up again in a bbr-dev thread recently where the patches helped throughput even with a 10Gbps NIC:

Background:

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 then BBR stopped sending after sending 2*BDP, 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 new 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.


For more info, please check out the video and/or slides from our team's presentation at the ICCRG session at IETF 101.


thanks,
neal

Reply all
Reply to author
Forward
0 new messages