* Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
@ 2020-08-24 14:35 Robert Bengtsson-Ölund
2020-08-24 16:13 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Robert Bengtsson-Ölund @ 2020-08-24 14:35 UTC (permalink / raw)
To: netdev
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
--
Robert Bengtsson-Ölund, System Developer
Software Development
+46(0)90-349 39 00
www.intinor.com
-- INTINOR --
WE ARE DIREKT
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
2020-08-24 14:35 Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y Robert Bengtsson-Ölund
@ 2020-08-24 16:13 ` Eric Dumazet
2020-08-24 18:39 ` Priyaranjan Jha
0 siblings, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2020-08-24 16:13 UTC (permalink / raw)
To: Robert Bengtsson-Ölund, netdev, Priyaranjan Jha,
Neal Cardwell, Yuchung Cheng
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@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 <priyarjha@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
2020-08-24 16:13 ` Eric Dumazet
@ 2020-08-24 18:39 ` Priyaranjan Jha
2020-08-25 9:01 ` Robert Bengtsson-Ölund
0 siblings, 1 reply; 6+ messages in thread
From: Priyaranjan Jha @ 2020-08-24 18:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Robert Bengtsson-Ölund, netdev, Neal Cardwell, Yuchung Cheng
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@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 <priyarjha@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 <priyarjha@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
2020-08-24 18:39 ` Priyaranjan Jha
@ 2020-08-25 9:01 ` Robert Bengtsson-Ölund
2020-09-29 17:25 ` Priyaranjan Jha
0 siblings, 1 reply; 6+ messages in thread
From: Robert Bengtsson-Ölund @ 2020-08-25 9:01 UTC (permalink / raw)
To: Priyaranjan Jha; +Cc: Eric Dumazet, netdev, Neal Cardwell, Yuchung Cheng
Much appreciated.
Thank you everyone.
/Robert
On Mon, 24 Aug 2020 at 20:39, Priyaranjan Jha <priyarjha@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.dumazet@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 <priyarjha@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 <priyarjha@google.com>
> > Signed-off-by: Neal Cardwell <ncardwell@google.com>
> > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
--
Robert Bengtsson-Ölund, System Developer
Software Development
+46(0)90-349 39 00
www.intinor.com
-- INTINOR --
WE ARE DIREKT
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
2020-08-25 9:01 ` Robert Bengtsson-Ölund
@ 2020-09-29 17:25 ` Priyaranjan Jha
2020-09-30 8:49 ` Robert Bengtsson-Ölund
0 siblings, 1 reply; 6+ messages in thread
From: Priyaranjan Jha @ 2020-09-29 17:25 UTC (permalink / raw)
To: Robert Bengtsson-Ölund
Cc: Eric Dumazet, netdev, Neal Cardwell, Yuchung Cheng
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-olund@intinor.se> wrote:
>
> Much appreciated.
>
> Thank you everyone.
> /Robert
>
>
> On Mon, 24 Aug 2020 at 20:39, Priyaranjan Jha <priyarjha@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.dumazet@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 <priyarjha@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 <priyarjha@google.com>
> > > Signed-off-by: Neal Cardwell <ncardwell@google.com>
> > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
>
>
>
> --
> Robert Bengtsson-Ölund, System Developer
> Software Development
> +46(0)90-349 39 00
>
> www.intinor.com
>
> -- INTINOR --
> WE ARE DIREKT
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y
2020-09-29 17:25 ` Priyaranjan Jha
@ 2020-09-30 8:49 ` Robert Bengtsson-Ölund
0 siblings, 0 replies; 6+ messages in thread
From: Robert Bengtsson-Ölund @ 2020-09-30 8:49 UTC (permalink / raw)
To: Priyaranjan Jha; +Cc: Eric Dumazet, netdev, Neal Cardwell, Yuchung Cheng
Thanks.
/Robert
On Tue, 29 Sep 2020 at 19:25, Priyaranjan Jha <priyarjha@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-olund@intinor.se> wrote:
> >
> > Much appreciated.
> >
> > Thank you everyone.
> > /Robert
> >
> >
> > On Mon, 24 Aug 2020 at 20:39, Priyaranjan Jha <priyarjha@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.dumazet@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 <priyarjha@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 <priyarjha@google.com>
> > > > Signed-off-by: Neal Cardwell <ncardwell@google.com>
> > > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > > > Signed-off-by: David S. Miller <davem@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-30 8:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-24 14:35 Request for backport of 78dc70ebaa38aa303274e333be6c98eef87619e2 to 4.19.y Robert Bengtsson-Ölund
2020-08-24 16:13 ` Eric Dumazet
2020-08-24 18:39 ` Priyaranjan Jha
2020-08-25 9:01 ` Robert Bengtsson-Ölund
2020-09-29 17:25 ` Priyaranjan Jha
2020-09-30 8:49 ` Robert Bengtsson-Ölund
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.