BBR v1 flows and cubic flows.

Skip to first unread message


Aug 21, 2021, 2:44:40 AM8/21/21
to BBR Development

Hi there.

I want to share some findings... with default BBR v1 running in a ubuntu machine...

1. I started three separate flows/downloads in a terminal , each downloading 4 gb file
2. the border router is a 4G LTE device.
3. Linunx VM is running under windows 10 and is NATTED.
4. What i am experiencing right now that when i open browser in windows 10 and try to surf the browsing is very slow , it seems like BBR v1 flows in LINUX VM have choked the cubic flows.
root@ubuntu:/# ss -tin
State            Recv-Q            Send-Q                           Local Address:Port                            Peer Address:Port            Process                                                                                                                                        
ESTAB            0                 0                                                
     bbr rto:204 rtt:0.222/0.077 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:14 bytes_sent:1228 bytes_acked:1229 bytes_received:506069209 segs_out:78946 segs_in:359574 data_segs_out:4 data_segs_in:359569 bbr:(bw:87819208bps,mrtt:0.133,pacing_gain:2.88672,cwnd_gain:2.88672) send 736576577bps lastsnd:671004 lastrcv:1496 lastack:1660 pacing_rate 1457628056bps delivery_rate 87819544bps delivered:5 app_limited retrans:0/1 rcv_rtt:14.951 rcv_space:2001709 rcv_ssthresh:3144640 minrtt:0.133
ESTAB            0                 0                                                
     bbr rto:984 rtt:210.063/192.905 ato:40 mss:1460 pmtu:1500 rcvmss:1400 advmss:1460 cwnd:14 bytes_sent:1228 bytes_acked:1229 bytes_received:660603501 segs_out:102315 segs_in:468896 data_segs_out:4 data_segs_in:468891 bbr:(bw:142438888bps,mrtt:0.082,pacing_gain:2.88672,cwnd_gain:2.88672) send 778433bps lastsnd:705704 lastrcv:280 lastack:308 pacing_rate 407069200bps delivery_rate 142439024bps delivered:5 app_limited rcv_rtt:1.708 rcv_space:631274 rcv_ssthresh:3144640 minrtt:0.082
ESTAB            0                 0                                                
     bbr rto:236 rtt:35.084/32.06 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:14 bytes_sent:1228 bytes_acked:1229 bytes_received:537402676 segs_out:85074 segs_in:381975 data_segs_out:4 data_segs_in:381970 bbr:(bw:77866592bps,mrtt:0.15,pacing_gain:2.88672,cwnd_gain:2.88672) send 4660814bps lastsnd:707992 lastrcv:32 lastack:120 pacing_rate 222531160bps delivery_rate 77866664bps delivered:5 app_limited busy:8ms rcv_rtt:22.969 rcv_space:2526712 rcv_ssthresh:3144640 minrtt:0.15

Neal Cardwell

Aug 21, 2021, 3:41:30 PM8/21/21
to MUHAMMAD AHSAN, BBR Development

Please note that with TCP and most other standard transport protocols (QUIC, etc.) the congestion control logic that governs the data transfer is the logic on the data sender. In the ss output you have shared, the bbr connections are bulk data receivers, since you are doing a download with these connections. (Note that in the ss output the bytes_acked field is less than the MTU, but bytes_received shows many hundreds of MBytes.)

So in your test the bbr congestion control logic is not in control of the downloads.

So if your web browsing session is slow while you are doing these downloads, a good guess would be that this is a standard bufferbloat scenario: the downloads are probably from an Internet site using Reno or CUBIC, and they are keeping the bottleneck buffer (likely in the LTE cell system) near full, and so the interactive web traffic is having to sit in long queues, causing the web downloads to feel sluggish.

If you want to compare the performance of bbr on your test device with cubic, you might try alternating trials where you upload (e.g., scp) a file from your test device to some place on the Internet, using (a) bbr, then (b) cubic. Or you could install a test kernel on a cloud service and download files from that cloud virtual machine to your local device.

best regards,


You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit
Reply all
Reply to author
0 new messages