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.
