STRING, can be read and
set, but not
Congestion control algorithm for the client connection. Available
values at this time are
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
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.
reno, it is a pure loss-based algorithm. It is more aggressive
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 solution recipes, which show real world use cases. Click RUN to provision a Fastly service, execute the code on Fastly, and see how the function behaves.
Fastly offers a myriad of different variables that you can log. See and test a large collection here.
User contributed notes
We welcome comments that add use cases, ideas, tips, and caveats. All comments will be moderated before publication. To post support questions, visit our support center and we'll find you the help you need.