CC_CHD(4)

📦 version 12.2, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 cc_chd — the CHD Congestion Control Algorithm 💖

okay bestie, sit down, hydrate, because we're talking about cc_chd(4) — a congestion control algorithm from the cc_chd kernel interfaces manual, and honestly? she's giving smart girl energy. ✨

🌸 NAME 🌸

cc_chd — the CHD Congestion Control Algorithm, no cap.

🦋 DESCRIPTION 🦋

okay so. CHD is basically HD's glow-up. Like, it takes the HD algorithm that lives in cc_hd(4) and levels it all the way up. 💅

What does it add? Two things, and both are iconic:

  • it's tolerant of packet loss that has nothing to do with congestion — so it doesn't panic when the loss isn't even its fault
  • it plays so much nicer with traditional loss-based TCP flows, especially when the bottleneck link is lightly multiplexed 🫶

and just like HD, the algorithm is on a mission: keep network queuing delays below a particular threshold (queue_threshold), and decide whether to shrink the congestion window (cwnd) probabilistically, based on its estimate of the network queuing delay. she's doing math in her head at all times, it's lowkey impressive.

so where does CHD differ from HD? three key aspects, and I'm obsessed:

  • The probability of cwnd reduction due to congestion is calculated once per round trip time, instead of every single time an acknowledgement is received like cc_hd(4) does. like, she's not checking her phone every two seconds, she's checking it once per RTT. boundaries. ✋
  • Packet losses that happen while the queuing delay is less than queue_threshold do not cause cwnd to be reduced. loss happens, she moves on, no drama 💀
  • CHD uses a shadow window to help regain lost transmission opportunities when competing with loss-based TCP flows. sneaky? no. strategic. 👑

✨ MIB Variables ✨

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

  • queue_threshold — Queueing congestion threshold (qth) in ticks. Default is 20.
  • pmax — Per RTT maximum backoff probability as a percentage. Default is 50.
  • qmin — Minimum queuing delay threshold (qmin) in ticks. Default is 5.
  • loss_fair — If 1, cwnd is adjusted using the shadow window when a congestion related loss is detected. Default is 1.
  • use_max — If 1, the maximum RTT seen within the measurement period is used as the basic delay measurement for the algorithm, otherwise a sampled RTT measurement is used. Default is 1.

🌈 SEE ALSO 🌈

go read these, bestie, they're the whole friend group:

cc_cubic(4), cc_hd(4), cc_htcp(4), cc_newreno(4), cc_vegas(4), h_ertt(4), mod_cc(4), tcp(4), khelp(9), mod_cc(9)

and the academic queen herself:

D. A. Hayes and G. Armitage, “Improved coexistence and loss tolerance for delay based TCP congestion control”, in 35th Annual IEEE Conference on Local Computer Networks, 24-31, October 2010. 📚

🎀 ACKNOWLEDGEMENTS 🎀

Development and testing of this software were made possible in part by grants from the FreeBSD Foundation and Cisco University Research Program Fund at Community Foundation Silicon Valley. funding besties, we love you 🫶

⭐ HISTORY ⭐

The cc_chd 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_chd congestion control module and this manual page were written by David Hayes <david.hayes@ieee.org>. thank you for your service, king 🫡

okay that's the whole page, you ate it, no crumbs. this one came from the Debian crew, dated September 15, 2011 — yes, 2011, she's vintage and still slaying 💖✨🎀

📦 where this page comes from