---
title: client.socket.congestion_algorithm
summary: null
url: >-
  https://www.fastly.com/documentation/reference/vcl/variables/client-connection/client-socket-congestion-algorithm
---

**Type:** STRING  
**Access:** can be read and set, but not unset

**Available in:** recv, deliver, log, error

Congestion control algorithm for the client connection. Available
values at this time are `cubic`, `reno`, or `bbr`, with `cubic` being the
default. VCL that sets this variable should read the value back
afterwards to confirm that the selection was able to be honored by the
kernel configuration.

_New Reno_, selected with the `reno` token, is the classic loss-driven
TCP (HTTP/1 and HTTP/2) congestion control approach. It is known for cyclically filling
and emptying buffers along the path, for performing poorly in the
face of non-congestion driven packet loss, and for being too
conservative in the face of situations like high bandwidth or high delay paths.

_Cubic_ is defined in [RFC 8312](https://www.ietf.org/rfc/rfc8312.txt).
Like `reno`, it is a pure loss-based algorithm. It is more aggressive
than `reno` and does a better job of effectively using high bandwidth
and high delay paths but still struggles in the presence of loss. This
aggressiveness also leads to consistent filling of on-path buffers and
the creating of bufferbloat and interference with latency-sensitive
applications like VOIP or gaming.

_BBR_ considers both loss and delay and explicitly seeks to maintain the
highest sending rate at a constant delay. BBR, due to its
consideration of buffering induced delay, is better at maintaining
shallow buffers and better network latency for other applications. BBR
is the newest of these algorithms and is still evolving and considered experimental.