TCP BBR congestion control

• Back to Proxy tuning main section

TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP congestion-control algorithm. 
Artica lets you switch the appliance from the default algorithm (CUBIC) to BBR with a single click on the proxy status page. 
The change applies immediately, needs no reboot and does not restart the proxy.
Available from Artica 4.50 SP8 with update 20260923-18 or later. 
 

Concept

Every TCP connection has a sender that decides how fast to push data. 
The congestion-control algorithm is the logic that makes this decision.

• CUBIC (the Linux default) is loss-based: 
  it speeds up until packets are dropped, then cuts its sending window sharply. 
  On a link that loses a few packets for reasons unrelated to congestion (Wi-Fi, 4G/5G, long-distance or VPN links), it keeps slowing down for nothing. 
  It also tends to fill router buffers before it detects a problem, which adds latency for everybody sharing the link (bufferbloat).
   
• BBR is model-based: 
  It continuously measures the bottleneck bandwidth and the minimum round-trip time of the path, and sends at that rate. 
  A random packet loss does not make it collapse, and it keeps router queues short.

Important: BBR acts on what the appliance sends

Congestion control is a sender-side mechanism. 
On a proxy, this means:

• Improved: 
  Everything the proxy sends. 
  Mainly the web pages and downloads it delivers to its users, and the uploads it forwards to Internet servers.
• Not changed: 
  The speed at which an Internet server sends data to the proxy. 
  That direction is governed by the algorithm of the remote server.

The biggest gain is therefore on the proxy-to-user leg when users sit behind a slow, distant or lossy link: 
branch offices over WAN or VPN, remote workers, Wi-Fi or mobile networks.

New connections only

The algorithm is chosen when a TCP connection opens. 
Connections that already exist keep their algorithm until they close; every new connection uses the new one. 
Nothing is interrupted, which is why no proxy restart is needed.

Performance benefits

• Higher throughput on lossy links. 
  A 1% packet loss is enough to cut CUBIC's throughput dramatically on a long-distance path; 
  BBR keeps close to the real available bandwidth.
   
• Better use of high-latency links. 
  On paths with a large round-trip time (intercontinental sites, satellite, VPN concentrators), BBR reaches full speed faster and holds it.
   
• Lower latency under load. 
  Because BBR does not fill router buffers, interactive traffic (web browsing, VoIP, remote desktop) sharing the same link stays responsive while large downloads run.
   
• Faster start of transfers. 
  Large downloads delivered by the proxy ramp up quicker, which shortens the time users wait for big files.
   
• No cost on a clean LAN. 
  On a fast, loss-free local network, BBR and CUBIC perform about the same. 
  Enabling BBR does not degrade such a network.

Use cases

Enabling TCP BBR

1. On the left menu, open Your proxy > Status.
2. In the Modules & filtering services card, find the TCP BBR tile and click on Parameters.

1. The dialog explains the feature and shows the current state read from the kernel. 
   Here BBR is disabled: the active algorithm is cubic.

1. Click on Enable TCP BBR. 
   The setting is saved and applied at once. 
   The diagnostic block is refreshed with the real kernel values: Active algorithm: bbr, Default queue: fq.

1. Close the dialog: the tile now shows Active and the values in use.

To go back to CUBIC, open the same dialog and click on the switch again.

Reading the status

REST API

The feature is driven by the articarest REST service (Unix socket /usr/share/artica-postfix/bin/run/articarest.sock, or the REST port with the usual access restrictions).

Example:

# curl -s -X POST --unix-socket /usr/share/artica-postfix/bin/run/articarest.sock http://localhost/system/bbr/1
{
  "success": true,
  "outcome": "applied",
  "data": {
    "configured": true,
    "cluster_managed": false,
    "cluster_mode": 0,
    "supported": true,
    "active": true,
    "state": "active",
    "available": ["reno", "cubic", "bbr"],
    "current_cc": "bbr",
    "current_qdisc": "fq",
    "message": ""
  }
}

The outcome field tells you what really happened:

• applied: the kernel now matches the setting.
• saved_unsupported: the setting is saved, but the kernel cannot run BBR.
• apply_failed: the setting is saved, but the kernel value differs from it.

The state field is one of active, inactive, unsupported or error.

Proxies behind a HaCluster load-balancer

On a HaCluster, BBR is best managed from the load-balancer: a single switch applies it to the load-balancer itself (which delivers the data to users) and to every proxy of the cluster. While the cluster manages BBR, the tile of each proxy shows HaCluster and its dialog no longer offers the switch. See TCP BBR on a HaCluster.

Troubleshooting

The dialog shows an error message when saving

The message comes from the appliance: missing privileges (you need proxy administrator rights), node managed by the HaCluster load-balancer, or REST service not reachable. 
The saved value is never hidden: the diagnostic block always shows the real kernel state.

Some connections still use CUBIC

That is expected: connections opened before the change keep their algorithm until they close.