CC_VEGAS(4)

📦 version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

💅 cc_vegas — the Vegas Congestion Control Algorithm 🎰✨

okay so this is the man page for cc_vegas(4), a section 4 kernel interfaces manual page, and bestie I promise it's less scary than it looks 🫶

NAME 🌸

cc_vegas — the Vegas Congestion Control Algorithm, literally right there in the name, no notes 💅

DESCRIPTION 💖

okay so the Vegas congestion control algorithm is doing math and honestly? it ate. it uses what the authors call the actual transmission rate and the expected transmission rate to figure out whether there's congestion hanging out along the network path. it's giving:

actual rate = (total data sent in a RTT) / RTT

expected rate = cwnd / RTTmin

diff = expected - actual

where RTT is the measured instantaneous round trip time and RTTmin is the smallest round trip time observed during the connection. tiny little baby RTT. the smallest one. 🥺

the algorithm's whole goal — its main character energy, if you will — is to keep diff between two parameters called alpha and beta, like so:

alpha < diff < beta

so if diff > beta, congestion is inferred (uh oh 😭) and cwnd gets decremented by one packet (or the maximum TCP segment size, whichever). but if diff < alpha? then cwnd is incremented by one packet. slay. and the way that alpha and beta govern the amount of buffering along the path? iconic, honestly.

the implementation was done in a clean-room fashion (very demure, very mindful) and is based on the paper referenced in the SEE ALSO section below 👇

IMPLEMENTATION NOTES 🧚

the time from the transmission of a marked packet until the receipt of an acknowledgement for that packet is measured once per RTT. periodt.

this implementation does not implement Brakmo's and Peterson's original duplicate ACK policy, and the reason is kind of a vibe check on modern hardware: clock ticks in today's machines are not as coarse as they were (i.e. 500ms) when Vegas was originally designed. we simply don't live in that timeline anymore 💀

also note bestie: modern TCP recovery processes such as fast retransmit and SACK are enabled by default in the TCP stack. no cap.

MIB Variables 🔥

the algorithm exposes the following tunable variables in the net.inet.tcp.cc.vegas branch of the sysctl(3) MIB:

  • alpha — query or set the Vegas alpha parameter as a number of buffers on the path. when you're setting alpha, the value must satisfy: 0 < alpha < beta. default is 1.
  • beta — query or set the Vegas beta parameter as a number of buffers on the path. when you're setting beta, the value must satisfy: 0 < alpha < beta. default is 3.

(notice the constraint is literally the same for both and it's the same as the algorithm's whole deal? we love consistency 💜)

SEE ALSO 👀

and the actual academic source, the moment, the blueprint:

L. S. Brakmo and L. L. Peterson, “TCP Vegas: end to end congestion avoidance on a global internet”, IEEE J. Sel. Areas Commun., 8, 13, 1465-1480, October 1995.

ACKNOWLEDGEMENTS 🎀

development and testing of this software were made possible in part by grants from the FreeBSD Foundation and the Cisco University Research Program Fund at Community Foundation Silicon Valley. we stan funding, fr fr 💖

HISTORY ⭐

the cc_vegas congestion control module first appeared in FreeBSD 9.0.

the module was first released in 2010 by David Hayes whilst working on the NewTCP research project at Swinburne University of Technology's Centre for Advanced Internet Architectures, Melbourne, Australia 🇦🇺🦋 more details are available at:

http://caia.swin.edu.au/urp/newtcp/

AUTHORS 👑

the cc_vegas congestion control module and this manual page were written by David Hayes <david.hayes@ieee.org>. an absolute legend, we love to see it 🫡

okay that's the whole page, bestie, you're officially a Vegas expert 🌈 also tiny sign-off moment: this page comes from the Debian source, dated May 13, 2021, and it's CC_VEGAS(4), which we already established, but it felt right to say it one more time 💀✨ go forth and not congest 🦋

📦 where this page comes from