client.socket.congestion_algorithm

STRING, can be read and set, but not unset.

Available inrecvdeliverlogerror

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 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. 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.

Try it out

client.socket.congestion_algorithm is used in the following code examples. Examples apply VCL to real-world use cases and can be deployed as they are, or adapted for your own service. See the full list of code examples for more inspiration.

Click RUN on a sample below to provision a Fastly service, execute the code on Fastly, and see how the function behaves.

Comprehensive logging

Fastly offers a myriad of different variables that you can log. See and test a large collection here.